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FOREWORD 

This  report  documents  cost  benefit  analyses  for  eight  messages 
that  require  manual  payments  in  the  Mechanization  of  Contract 
Administration  Services  (MOCAS)  system,  as  well  as  Electronic 
Data  Interchange  (EDI)  initiatives  pertaining  to  contract  pay¬ 
ments  at  Defense  Logistics  Agency  (DI.A)  and  Defense  Finance  and 
Accounting  Service  (DFAS)  payment  centers.  MOCAS  pays  invoices 
automatically  if  the  data  base  information  exactly  matches  the 
contractor  invoice  information.  Invoices  are  paid  manually  if 
an  error  has  been  made  anywhere  in  the  data  input  process,  or  in 
cases  where  a  decision  (usually  at  the  clerical  level)  is  required 
to  control  expenditure  of  government  funds. 

The  results  show  that  numerous  manual  payments  could  be  avoided 
by  implementing  several  procedural  and  MOCAS  system  changes.  The 
relative  frequencies  of  the  different  conditions  causing  manual 
payments  were  determined  by  a  Pareto  analysis.  It  used  informa¬ 
tion  from  a  special  data  base  built  with  information  collected 
from  each  DI.A  Payment  Center.  The  study  estimates  that  by 
implementing  all  the  recommendations  the  payment  centers  could 
save  over  $10  million  annually.  This  results  from  saving  444 
workyears,  195  of  which  are  in  the  manual  payment  area.  The 
effect  of  the  workyear  savings  in  the  manual  payment  area  would 
be  to  increase  the  overall  API  rate  from  the  current  50  percent 
to  an  estimated  64  percent.  Besides  the  savings  above,  that 
result  when  the  messages  that  were  analyzed  appear  alone,  an 
additional  17  workyears  will  be  saved  by  eliminating  the  manual 
payments  occurring  when  these  messages  appear  with  each  other. 

This  would  increase  the  overall  API  rate  to  over  65  percent. 

Based  on  the  results  of  this  study,  the  MOCAS  payment  process 
should  be  changed  to  implement  the  recommendations  in  this  report. 


ROGER  €.  ROY 

Assistant  Director 

Office  of  Policy  and  Plans 
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INTRODUCTION 


The  Defense  Contract  Management  Command  (DCMC)  paid  1,598,506  invoices 
in  Fiscal  Year  (FY)  1990.  This  contract  payment  function  is  very  labor 
intensive.  Contract,  contract  modification,  contractor  invoice,  and 
material  acceptance  data  all  require  substantial  clerical  input.  When 
data  matches  and  certain  contract  information  has  been  validated,  the 
Mechanization  of  Contract  Administration  Services  (MOCAS)  system  will 
pay  invoices  automatically.  Every  invoice  goes  through  this  validation 
process,  called  the  Automatic  Payment  of  Invoices  (API)  system.  If 
MOCAS  contains  data  found  to  be  erroneous  or  that  cannot  be  validated, 
then  payment  by  MOCAS  is  only  partly  automatic  (because  the  invoice 
still  goes  through  the  API  system).  However,  in  this  case  additional 
manual  work  has  to  be  done  by  a  payment  clerk. 

Some  tasks  (such  as:  contract,  modification,  invoice,  and  acceptance 
data  input;  filing;  reconcil iation,  etc.)  are  done  for  all  invoices 
regardless  of  whether  the  payment  is  automatic  or  manual.  It  is 
estimated  that  75  percent  of  personnel  involved  in  contractor  payment 
(over  1,700  people)  perform  these  functions  that  are  common  to  both 
automatic  and  manual  payments.  The  remaining  25  percent  (almost  600 
people)  work  solely  on  functions  related  to  making  payments  manually. 
See  Appendix  A  for  details  of  these  estimates.  Since  the  average  API 
rate  for  all  payment  centers  is  50  percent,  799,253  payments  are  made 
manually  rather  than  automatically.  Any  changes  that  increase  the  API 
rate  (decrease  the  number  of  manual  payments),  decreases  the  amount  of 
work  done  manually. 

The  Administrator  of  the  Defense  logistics  Agency  (DLA)  Finance  Center 
(DFC)  asked  the  DLA  Operations  Research  Office  Chicago  (D0R0-C)  to 
investigate  and  analyze  the  causes  of  manual  payments  of  invoices  in 
the  Mechanization  of  Contract  Administration  Services  (MOCAS)  system. 

He  felt  that  the  use  of  the  API  system  was  not  as  great  as  it  could  be, 
but  did  not  have  the  analytical  evidence.  He  wanted  to  know  if 
operational  improvements  could  be  made  to  increase  the  API  rate.  We 
were  also  to  perform  a  cost-benefit  analysis  of  manual  Material 
Acceptance  and  Accounts  Payable  Report  (MAAPR)  conditions  which  prevent 
API. 


II.  METHODOLOGY 

A  sample  data  base  was  created  by  downloading  two  weeks  of  daily  manual 
MAAPRs  from  each  Defense  Contract  Management  Region  (DCMR)  payment 
center  and  the  DFC.  MAAPR  messages  that  were  for  information  only  were 
eliminated,  leaving  only  messages  about  conditions  that  prevent  API. 
Those  messages  that  only  stop  API  under  certain  conditions  (e.g.,  final 
shipment  only,  if  not  progress  payment,  etc.)  were  counted  only  when 
these  conditions  were  met.  A  total  of  26,035  MAAPR  messages  on  19,620 
manual  MAAPR  reports  were  collected.  A  Pareto  analysis  was  done  to 
determine  the  relative  frequency  of  the  MAAPR  messages  causing  manual 
payments.  This  data  base  also  enabled  the  simulation  of  the  impact  of 
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alternatives  to  current  operating  procedures.  A  detailed  breakdown  of 
the  frequency  of  all  manual  MAAPR  messages  by  payment  center  is  in 
Appendix  B. 

The  methodology  of  this  project  is  to  analyze  the  operations  used  with 
each  MAAPR  message.  In  so  doing,  the  costs,  savings  and  risks  of  the 
status  quo,  as  well  as  plausible  alternatives,  are  examined  where 
appropriate  and  to  the  extent  worthwhile. 

A  total  of  nine  manual  MAAPR  messages  were  studied  in-depth.  They  were 
selected  based  on  the  Pareto  chart  and  the  potential  for  payback.  In 
addition  to  these  individual  messages,  a  cost-benefit  analysis  was  done 
on  current  and  potential  Electronic  Data  Interchange  (EDI)  initiatives 
within  DLA  pertaining  to  the  contract  payment  function.  The  messages 
studied  include: 

-  the  three  most  frequent  messages  (MAAPR- INV  $  NOT  EQUAL, 

EVIDENCE  OF  SHIPMENT  REQUIRED,  and  MANDATORY  REVIEW/OTHER) 

-  the  three  Transportation  messages  (FOB  ORIGIN/MINIMUM  SIZE, 
GUARANTEED  MAXIMUM  SHIPPING  WT  and  TRANSPORTATION  AMT  EXCEEDED) 

NOTE:  The  TRANSPORTATION  AMT  EXCEEDED  message  was  documented  under 
separate  cover,  "Threshold  for  Transportation  Charge  Review  Cost 
Benefit  Analysis",  DCMDC  Operations  Research  Office,  September  1990 

-  the  two  messages  used  in  collecting  funds  from  contractors  (VO 
DEDUCTION  PENDING  and  CONTRACTOR  INDEBTEDNESS) 

-  the  only  message  involving  a  contract  quality  provision  (FIRST 
ARTICLE  APPROVAL  REQUIRED) 

An  analysis  of  the  cost  of  a  manual  payment  of  an  invoice  was  also 
performed.  These  costs  are  those  that  are  additional  to  those  that  are 
common  to  both  manual  and  automated  payments.  This  cost  was  determined 
to  be  $19.98  per  manual  payment.  Appendix  C  details  this  analysis. 


III.  ANALYSIS 

Detailed  analyses  of  the  eight  MAAPR  messages  and  the  EDI  initiatives 
may  be  found  in  the  following  appendices: 

-  MAAPR- INV  $  NOT  EQUAL  --  Appendix  D 

-  EVIDENCE  OF  SHIPMENT  REQUIRED  --  Appendix  E 

-  MANDATORY  REVIEW/OTHER  --  Appendix  F 

-  VO  DEDUCTION  PENDING  --  Appendix  G 

-  CONTRACTOR  INDEBTEDNESS  --  Appendix  G 
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-  FIRST  ARTICLE  APPROVAL  REQUIRED  --  Appendix  H 

-  FOB  ORIGIN/MINIMUM  SIZE  --  Appendix  I 

-  GUARANTEED  MAXIMUM  SHIPPING  WT  --  Appendix  I 

-  ELECTRONIC  DATA  INTERCHANGE  (EDI)  INITIATIVES  FOR  CONTRACT 
PAYMENT  --  Appendix  J 


IV.  RECOMMENDATIONS 

Recommendations  involve  a  combination  of  procedural  and  system  changes, 
many  of  which  are  very  minor.  Procedural  changes  (along  with  very 
small  MOCAS  changes)  include  removing  the  following  from  the  list  of 
messages  preventing  API:  FIRST  ARTICLE  APPROVAL  REQUIRED  (Appendix  H), 
FOB  ORIGIN/MINIMUM  SIZE  (Appendix  I),  and  GUARANTEED  MAXIMUM  SHIPPING 
WT  (Appendix  I).  It  was  determined  that  preventing  API  because  of 
these  conditions  was  not  cost  effective. 

System  changes  (which  may  also  require  procedural  changes  to  implement) 
would  involve  altering  the  way  certain  messages  are  handled.  MAAPR-INV 
$  NOT  EQUAL  would  no  longer  stop  API  in  cases  where  the  contractor 
invoiced  for  less  than  the  MAAPR  amount  (Appendix  D).  To  resolve  one 
of  the  problems  when  the  contractor  invoices  for  more  than  the  MAAPR 
amount,  MOCAS  would  indicate  on-line  when  transportation  charges  are 
authorized  (Appendix  D).  The  current  procedures  for  dealing  with 
EVIDENCE  OF  SHIPMENT  REQUIRED  (Appendix  E)  would  remain  in  effect. 
However,  an  indicator  would  be  placed  on  the  Invoice  Data  input  screen 
alerting  the  input  clerk  that  Evidence  of  Shipment  is  indeed  required. 
The  MANDATORY  REVIEW/OTHER  (Appendix  F)  message  would  no  longer  be 
generated  along  with  the  AWAITING  HARD  COPY  RECEIPT  message.  Once  the 
hard  copy  of  a  contract  is  received,  it  weld  eliminate  the  initial 
message  and  replace  it  with  a  new  message  stating  that  the  hard  copy 
still  needs  to  be  reviewed.  All  MANDATORY  REVIEW/OTHER  messages  that 
have  no  accompanying  explanation  of  their  existence  would  be  purged 
from  the  data  base.  A  new  message  would  be  established  for  lump  sum 
deductions,  now  being  processed  under  the  VO  DEDUCTION  PENDING  and 
CONTRACTOR  INDEBTEDNESS  messages  (Appendix  G). 

Other  system  changes  are  more  extensive  in  nature.  The  Military 
Standard  Contract  Administration  Procedures  (MILSCAP)  contract 
abstracts  would  be  enhanced  to  include  sufficient  data  on  which  to  base 
payment  (Appendix  J).  This  would  include  adding  data  fields  for 
necessary  information  and  also  changing  the  method  of  data  transfer 
from  fixed  length  records  to  variable  length  records.  Efforts  are 
already  under  way  to  make  these  options  viable.  So  far,  the  efforts 
have  met  with  varying  degrees  of  success.  The  VO  DEDUCTION  PENDING  and 
CONTRACTOR  INDEBTEDNESS  messages,  as  well  as  lump  sum  deduction 
processing  (Appendix  G),  would  be  automated.  Once  entered  into  the 
data  base,  there  would  be  no  more  manual  payments  in  these  situations. 
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A  strictly  procedural  change  would  have  Transportation  Specialists 
sample  compliance  reviews  for  the  FOB  Origin  -  Minimum  Size  Shipments 
and  Guaranteed  Shipping  Characteristics  clauses  (Appendix  I). 

The  savings  from  implementing  the  EDI  initiatives  in  Appendix  J  are 
potentially  over  $8  million  annually.  This  corresponds  to  a  savings  of 
339  workyears,  most  of  which  come  from  the  tasks  common  to  both  API  and 
manual  payments  (contract  and  invoice  data  input).  The  remaining  44 
workyears  are  in  the  manual  payment  area.  The  remaining  minor  systems 
and  procedural  changes  (estimated  to  have  a  onetime  cost  of  $10,000) 
could  save  $2.25  million  per  year.  This  savings  corresponds  to  85 
workyears  (8  of  which  would  be  in  Transportation,  the  rest  in  the 
manual  payment  area).  Another  $550,000  could  be  saved  by  automating 
lump  sum  deductions  and  collecting  funds  owed  by  contractors.  This 
should  be  used  to  justify  a  systems  change  now,  if  Contract  Payment  and 
Reporting  (CPR)  is  not  implemented  shortly.  Implementing  all  of  the 
recommendations  in  this  study  would  save  over  $10  million,  or  444 
workyears.  Of  these  workyears,  141  are  in  the  manual  payment  area, 
serving  to  increase  the  API  rate  from  the  current  50  percent  to  an 
estimated  64  percent.  These  analyses  estimate  savings  only  for  when 
the  messages  analyzed  appear  alone.  Accounting  for  those  manual 
payments  occurring  when  the  analyzed  messages  appear  together  would 
save  17  more  workyears  in  the  manual  payment  area.  This  would  increase 
the  overall  API  rate  to  over  65  percent. 

It  is  recommended  that  the  Pareto  chart  created  from  data  downloaded 
from  the  payment  centers  be  generated  periodically  (quarterly, 
semiannually,  or  annually).  It  would  give  management  a  tool  to  focus 
on  the  messages  causing  the  most  manual  payments  and  measure  the 
results  of  efforts  to  increase  the  API  rate. 
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APPENDIX  A 


Percent  of  Payment  Personnel  Morking  Tasks  Cannon  tn  Both 
the  API  end  Benue  I  Payment  Process  Vs  Manual  Payment  Alone 
(Samp I*  of  4  Payment  Centers) 

Payment  Center:  ATL  CHi  DfC  STL  Total 


Contract  Payment  Personnel: 

a 

* 

s 

1 

4 

* 

<* 

t 

t 

a 

1 

Common  to  both  API  A  Manual  Pays: 

a*  Reconciliation 

6 

4 

12 

13 

6? 

7 

2 

2 

87 

7 

b-  File  Clerks 

S 

4 

5 

5 

20 

2 

2 

2 

32 

3 

c-  K  Data  Input 

12 

8 

6 

6 

69 

8 

14 

12 

101 

8 

d-  Invoice  Input 

7 

5 

4 

4 

41 

5 

8 

7 

60 

5 

e-  Contractor  Relations(l) 

2 

1 

1 

1 

8 

1 

1 

1 

12 

1 

f-  Other  (2) 

51 

36 

24 

25 

481 

53 

26 

22 

582 

46 

Supervisors  (For  a*f  above) 

IS 

13 

13 

14 

27 

3 

18 

15 

76 

6 

Total  API  Related 

101 

71 

05 

68 

713 

78 

71 

60 

950 

75 

Only  for  Manual  Payments: 

e-  Payment  Clerks 

31 

22 

23 

24 

152 

17 

39 

33 

245 

19 

t-  Contractor  Relations!!) 

4 

3 

3 

3 

15 

2 

3 

3 

25 

2 

Supervisors  (For  e-t  above) 

6 

4 

4 

4 

29 

3 

6 

5 

45 

4 

Total  Manual  Payment  Related 

41 

29 

30 

32 

196 

22 

48 

40 

315 

25 

__ 

. 

_ 

. 

_ _ 

_ 

. 

_ „ 

_____ 

Total  CF  Less  Travel  and  Payroll 

142 

100 

95 

100 

909 

100 

119 

100 

1265 

100 

Botes: 

1.  More  Contractor  Relations  effort  is  due  to  manual  payment  than  API,  therefore  the  people  doing 
this  mork  are  prorated  appropriately. 

2.  'Other'  includes  Disbursing,  Technical  Support,  Accounting,  Secretaries  and,  tor  DFC, 
Administration. 
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MAAPR  Messages  That  Cause  Manual  Payment  of  Invoices 
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APPENDIX  C 


Cost  of  a  Manual  Payment 

A.  Methodology.  The  methodology  for  determining  the  additional  cost 
of  a  manual  pay,  above  the  cost  of  the  work  that  is  associated  with 
both  manual  and  automated  pays,  is: 

1.  Find  data  for  the  #  of  workers  doing  manual  pays  and  the 

#  of  manual  pays  in  a  year. 

2.  Calculate: 

#  of  Manual  Pays  =  #  of  Manual  Pays  Per  Year _ 

Per  Worker  Per  Day  #  of  Workers  Doing  Manual  Pays  X  260 

3.  Calculate: 

Additional  Cost  =  Cost  Per  Manual  Pay  Worker  Per  Day 

Per  Manual  Pay  #  of  Manual  Pays  Per  Worker  Per  Day 

B.  Calculations 

1 .  Data 

a.  The  Effective  Number  of  DFC  and  DCMC  Employees  Working  Only 
on  Manual  Payments 

(1)  Total  DFC  and  DCMC  personnel  in  the  Accounting  and 
Finance  Division  (CF)  was  2,579  at  the  end  of  FY  90.  (On-board 
personnel  from  organization  charts  of  payment  centers.)  This  does  not 
include  any  Los  Angeles  or  New  York  personnel  except  for  10  in 
international  payment  in  New  York. 

(2)  Total  CF  employees  must  be  reduced  by  the  number  of 
employees  in  Payroll  and  Travel.  They  do  not  work  on  contract  payment 
processing.  This  area  is  10.5  percent  of  CF  or  270  people.  This 
leaves  2,309  employees. 

(3)  Of  the  2,309  employees  who  work  on  contract  payment 
processing,  1,732,  (75  percent)  do  keypunch-input  of  invoices  and 
contracts,  filing,  reconciliation,  etc.  (See  Appendix  A.)  These 
tasks,  and  some  others,  are  performed  for  all  pays  (or  contracts) 
regardless  of  whether  the  pay  is  manual  or  through  the  API  System. 

This  manual  work  therefore  is  more  properly  attributed  to  the  API 
System.  Therefore  the  workyears  are  removed  from  the  calculation  of 
the  work  done  on  manua’  pays.  This  leaves  577  (25  percent). 

b.  Number  of  Manual  Pays  Per  Year.  Total  DCMC  FY  90  invoices 
processed  is  1,598,506  (report  RCS  448).  The  API  rate  is  50  percent, 
so  half  of  these,  (799,253)  were  manual  pays. 
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2.  Manual  Pays  Per  Worker  Per  Day.  There  are  1,385  manual  payments 
per  year  per  person  working  on  manual  payments  (799,253/577).  There 
are  260  paid  days  in  a  year  (5  X  52  weeks).  Therefore  there  are  5.327 
manual  pays  per  paid  day  per  person  doing  manual  pays.  This  figure  is 
for  all  paid  days  (see  note  below),  therefore  holiday,  annual,  sick 
leave  and  training  is  accounted  for. 

3.  Additional  Cost  Per  Manual  Pav.  The  additional  cost  of  a  manual 
pay  (above  the  manual  part  of  the  API  work)  is: 

fringe  ben. 

GS  6  St.  5  adjustment 

$10. 27/hr.  X  1.2955  X  8  hours  =  $106.44  per  paid  day 


$106.44/dav  =  $19.98  per  manual  pay 

5.327  manual  pays/day 


NOTE:  Paid  days  can  be  converted  to  work  days  by  using  a  22  percent 
adjustment  factor  to  account  for  leave  (18  percent)  and 
training  (4  percent).  Therefore  260  paid  days  equate  to  213 
work  days.  6.50  manual  pays  per  person  are  done  on  work 
days.  (The  cost,  of  course,  is  the  same.) 
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I.  INTRODUCTION.  A  detailed  frequency  breakdown  of  all  manual 
Material  Acceptance  and  Accounts  Payable  Report  (MAAPR)  messages  by 
payment  center  is  in  Appendix  B.  The  ten  most  frequent  messages  are 
shown  in  Attachment  1  to  this  Appendix.  Table  1  contains  the  overall 
breakdown  of  messages  in  the  sample. 

TABLE  1 


Estimated  % 

Cause  of  Manual  MAAPR  Message  Occurrence 

MAAPR  -  Invoice  $  Amount  Not  Equal: 


Contractor  Invoices  for  Less  than  MAAPR:  10 
Contractor  Invoices  for  More  than  MAAPR: 
Modification  Receipt-Timing  and/or 
Transportation  Charge  Related  (1)  12 

Other  8 

Subtotal  30 

Other  non-clause  Related:  37 


Contract  Clause  Related: 

4  Clauses  Cause  (2)  26 

19  Clauses  (Each  Less  Than  1.3%)  Cause  7 

Subtotal  _33 

Total  100 


Notes: 

1.  Transportation  charges  on  Commercial  Bills  of  Lading  (CBLs) 
are  authorized.  The  contractor  has  properly  included  the 
charge  in  the  bottom  line  invoice  amount.  However,  the 
itemized  CBL  charge  was  not  separately  input  into  the 
Mechanization  of  Contract  Administration  Services  (MOCAS) 
system.  This  may  occur  either  because  the  CBL  charge  was  not 
itemized  by  the  contractor,  or  if  itemized,  was  overlooked  and 
not  input.  As  a  result,  the  invoice  exceeds  the  MAAPR  by  the 
amount  of  the  transportation  charge. 

2.  The  four  clause  related  messages  are:  EVIDENCE  OF  SHIPMENT 
REQUIRED,  WITHHOLD,  FIRST  ARTICLE  APPROVAL  REQUIRED,  and  FOB 
ORIGIN/MINIMUM  SIZE. 

This  table  shows  that  one  message  (MAAPR-INV  $  NOT  EQUAL)  occurred  on 
30  percent  of  all  the  MAAPRs  in  the  sample.  This  message  was  studied 
first  because  the  potential  payback,  due  to  the  frequency  of 
occurrence,  was  considered  high.  The  results  of  studying  the  MAAPR-INV 
$  NOT  EQUAL  message  is  in  two  parts.  Paragraph  II  analyzes  invoices 
less  than  the  MAAPR  amount  and  paragraph  III  analyzes  invoices  that  are 
for  more. 
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II.  CONTRACTOR  INVOICES  FOR  LESS  THAN  MAAPR  AMOUNT 


A.  Analysis.  A  manual  MAAPR  is  generated  if  the  contractor's 
invoice  and  the  corresponding  amount  in  the  Mechanization  of  Contract 
Administration  Services  (MOCAS)  system  are  not  equal.  The  only 
exception  is  if  the  difference  is  less  than  $10  AND  the  invoice  is  less 
than  the  amount  authorized  in  MOCAS.  Such  invoices  are  paid 
automatically  by  the  Automatic  Payment  of  Invoices  (API)  System.  The 
$10  threshold  was  implemented  to  account  for  small  rounding  errors 
resulting  from  extension  of  unit  prices. 

If  the  contractor  submits  an  invoice  that  is  more  than  $10  below  the 
corresponding  amount  authorized  in  the  contract,  a  manual  pay  is 
generated.  The  payment  clerk  pulls  the  hard  copy  contract,  verifies 
the  data  base  (DB),  corrects  the  DB  if  required,  and  then  manually  pays 
the  invoice  amount.  If  the  invoice  is  less,  and  the  DB  is  correct,  the 
payment  clerk  still  pays  only  the  invoice  amount.  The  payment  clerk 
does  not  notify  the  contractor  that  the  invoice  amount  is  less  than  the 
authorized  amount. 

B.  Alternatives.  Three  alternatives  were  considered:  (1)  change 
the  system  to  allow  for  more  expeditious  processing  of  these  payments, 

(2)  change  the  threshold  to  a  higher  amount  ($25,  $100  etc.),  and 

(3)  eliminate  the  $10  threshold  and  pay  any  invoice  less  than  the 
authorized  amount. 

1.  Change  the  wav  these  payments  are  handled.  Alternatives 
for  such  changes,  that  seemed  to  show  promise,  would  require 
significant  programming  work.  The  most  promising  alternative  would  be 
to  divert  these  invoices,  and  review  them  in  batches,  for  just  this 
condition.  A  manual  listing  could  be  generated  for  a  single  payment 
clerk  to  review.  Each  item  on  the  list  could  then  in  some  way  be 
verified  and  then  released  to  the  API  system.  Some  economies  could  be 
realized  by  having  a  dedicated  clerk  researching  this  single  message. 
The  documentation  associated  with  the  manual  pay  could  be  avoided. 
Unfortunately,  this  would  be  too  big  a  process  and  programming  change 
to  be  realistically  completed  in  the  near  term.  And  the  returns  would 
be  limited. 

2.  Change  the  dollar  amount  of  the  threshold.  This  does  not 
appear  to  be  a  worthwhile  option.  Raising  the  threshold  to  $50  would 
have  only  eliminated  111  manual  payments  in  our  sample.  A  $100 
threshold  would  have  eliminated  218  manual  payments.  Further 
increasing  the  threshold  raises  questions  as  to  whether  the  threshold, 
at  any  level ,  has  merit. 

3.  Remove  the  threshold.  Close  analysis  of  the  risk  involved 
shows  this  option  to  be  viable  and  cost  effective.  Removing  the 
threshold  could  reduce  manual  payments  by  about  6  percent  based  on  our 
sample.  (Several  MAAPR  messages  that  can  cause  manual  pay  could  appear 
on  the  same  MAAPR.  However,  the  MAAPR- INV  $  NOT  EQUAL  message,  when 
the  invoice  is  LESS  than  the  MAAPR  amount,  appeared  alone  1,143  times.) 
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This  represents  a  potential  savings  of  $0.94  million  per  year.  (The 
incremental  cost,  the  difference  between  paying  API  versus  manually 
averages  $19.98  per  pay.  See  Appendix  C  for  calculations.  There  would 
be  about  46,000  manual  payments  averted  annually.) 

C.  Analysis  of  Objections  or  Possible  Risks.  In  order  to  assess 
the  possible  risks  of  removing  the  threshold,  several  experts  on  the 
MOCAS  system  were  interviewed  at  Defense  Contract  Management  District 
North  Central  (DCMDC-C),  Defense  Logistics  Agency  Programs  Standards 
Support  Office  (DPSSO),  DLA  Finance  Office  (DLA-CF),  and  the  DLA 
Finance  Center  (DFC).  They  identified  several  possible  risks: 

1 .  Contract  Amount  Incorrectly  Keypunched 

Objection  or  Possible  Risk:  If  the  contract  amount  was  incorrectly 
keypunched,  so  that  the  dollar  value  was  too  high  (e.g.,  an  extra  zero 
was  input)  AND  the  contractor  submitted  an  invoice  higher  than 
authorized  but  less  than  the  amount  of  the  keypunch  error,  the 
contractor  could  be  overpaid  under  the  proposed  change. 

Evaluation:  At  the  contract  closeout  reconciliation,  this  condition 
would  result  in  an  audit  and  a  collection  action.  (Under  the  present 
system  the  input  error  would  be  corrected  and  the  contractor  would  be 
paid  the  proper  amount.) 

2.  Invoice  Amount  Incorrectly  Keypunched 

Objection  or  Possible  Risk:  The  payment  center  could  keypunch  the 
invoice  amount  improperly  at  an  amount  less  than  the  MAAPR  amount. 

Also,  contractors  could  invoice  for  less  if  they  include  their  discount 
in  the  "bottom  line"  invoice  amount  (although  they  are  not  supposed  to 
do  this.)  Under  the  proposed  change  both  situations  would  pay 
contractors  less  than  they  are  entitled.  This  could  result  in  interest 
payments  by  DLA.  It  would  also  result  in  additional  billing  by  the 
contractor  and  another  manual  pay. 

Evaluation:  As  mentioned  above,  dramatic  payoff  is  possible  from 
handling  all  pays  for  this  MAAPR  automatically.  Therefore,  if  it  is 
necessary  to  eliminate  this  particular  type  of  keypunch  error  to 
automate  these  pays,  action  should  be  taken  to  do  so.  (True  keypunch 
errors  of  this  type  are  fairly  rare.)  To  eliminate  the  problem,  a 
screening  capability  should  be  incorporated  into  the  invoice  input 
system  to  test  for  keypunch  error  simultaneously  with  the  initial 
keypunching  input  of  the  invoice.  If  after  initial  input  the  amount  is 
different,  either  more  or  less  than  the  MAAPR  amount,  the  screen  should 
give  a  clear  message  that  there  is  a  mismatch.  The  payment  clerk  would 
then  be  instructed  to  recheck  the  invoice  amount.  This  kind  of 
verification  is  highly  effective  and  involves  virtually  no  extra  work. 
It  "corrects"  errors  by  preventing  them. 
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3.  Modification  Lowered  Contract  Price 


Objection  or  Possible  Risk:  Problems  could  also  arise  if  a 
modification  was  made  to  the  contract  which  lowered  the  unit  price  and 
that  modification  was  not  entered  into  MOCAS  prior  to  processing  the 
invoice.  In  this  case,  if  the  contractor  submitted  the  invoice  using 
the  higher  (original  contract)  unit  price,  an  overpayment  could  result. 

Evaluation:  At  the  contract  closeout  reconciliation,  this  would  result 
in  an  audit  and  collection  action.  If  the  payment  office  does  not  have 
a  hard  copy  of  the  modification,  this  would  also  happen  with  the 
current  system.  (Paragraph  V  B  2  of  this  Appendix  recommends  a  change 
that  would  also  solve  this  problem.) 

4.  Contract  Payment  Reconciliation  Work 

Objection  or  Possible  Risk:  All  contracts  must  be  reconciled  before 
closeout.  By  eliminating  the  $10  threshold,  the  reconciliation  mil  be 
more  involved. 

Evaluation:  This  would  happen  only  in  those  relatively  few  cases  where 
a  keypunch,  or  contract  modification  type  error  actually  did  result  in 
too  high  a  value  in  the  DB.  In  other  words,  in  most  cases  the  error 
does  not  exist,  there  is  no  change  to  the  DB,  and  reconciliation  would 
be  the  same  as  with  the  present  system. 

5.  Contractors  Will  Not  Invoice  Accurately 

Objection  or  Possible  Risk:  Contractors  will  not  have  incentive  to 
complete  invoice  documents  properly  and  accurately  if  they  know  the 
payment  center  will  pay  when  a  discrepancy  exists.  As  a  result, 
reconciliation  workload  will  rise.  Reconciliation  will  be  more 
difficult. 

Evaluation:  There  is  no  apparent  incentive  that  would  cause  a 
contractor  to  deliberately  invoice  for  less.  The  contractor  will 
always  want  the  full  amount  that  is  due.  As  a  result  there  should  be 
no  additional  reconciliations.  (One  exception  is  the  possibility  that 
a  modification  has  decreased  the  contract  amount.)  Some  of  the 
discrepancies  between  the  MAAPR  and  invoice  dollar  amounts  should  be 
discovered  by  contractors  after  they  invoice.  If  so,  they  will  invoice 
for  the  differential  and  there  would  not  be  added  work  during 
reconciliation. 

Information  showing  that  the  contractor  invoiced  for  less  than  the 
MAAPR  amount  is  included  on  the  manual  Form  477,  Advice  of  Payment. 

When  there  is  a  manual  payment  this  form  is  part  of  the  reconciliation 
documentation  and  helps  with  that  process.  The  subvoucher,  invoice, 
MAAPR  and  other  supporting  documents  are  also  part  of  reconciliation 
documentation.  When  payment  is  API,  there  is  np  manual  Form  477  with 
the  other  reconciliation  documentation.  However,  there  is  no 
significant  difference,  in  work  time,  for  the  reconciliation  process 
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when  there  is  a  manual  Form  477  versus  when  there  is  not.  DPSSO 
estimates  the  time  to  do  a  reconciliation  at  18  minutes  and  the  added 
time  when  there  is  no  manual  Form  477  at  1-2  minutes.  As  a  result,  the 
benefits  of  paying  these  invoices  API  (since  all  other  considerations 
will  enable  such  payment)  far  outweigh  the  relatively  small  added  cost 
in  reconciliation. 

D.  Conclusion.  There  is  no  benefit  to  checking  MOCAS  for  contract 
input  errors  when  the  contractor  invoices  for  more  than  $10  below  the 
corresponding  MOCAS  amount.  This  is  because  there  is  very  little  risk 
to  paying  such  invoices.  After  all,  we  are  obligated  to,  and  do,  pay 
the  lesser  amount  anyway. 

The  limited  risk  is  due  to  the  possibility  that  an  amount  could  be 
incorrectly  keypunched  into  MOCAS  that  is  less  than  that  on  the 
invoice.  This  error  could  be  eliminated  by  comparing  the  input  amount 
to  the  MOCAS  amount  on-line  and  providing  an  on-screen  alert  for 
discrepancies. 

The  associated  manual  pays  consume  34  workyears  costing  $0.94  million 
per  year. 


III.  CONTRACTOR  INVOICES  FOR  MORE  THAN  MAAPR  AMOUNT 

A.  Analysis.  The  MAAPR-INV  $  NOT  EQUAL  message,  when  the 
contractor  invoices  for  more  than  the  MAAPR,  is  about  20  percent  of  all 
MAAPR  messages  that  cause  manual  payments.  We  estimate  that  half  of 
these  occur  because  contract  modifications  are  not  received  in  a  timely 
manner.  This  can  happen  when  an  increase  modification  for  a  new  amount 
has  been  implemented.  That  is,  if  the  contractor  invoices  for  the  new, 
correct  amount  before  the  payment  center  receives  a  hard  copy  of  the 
modification  from  the  buying  command,  or  inputs  it  to  MOCAS,  a  manual 
pay  results. 

Of  the  remaining  half  of  these  messages,  about  50  percent  are  estimated 
to  be  due  to  overlooking  to  input  a  CBL  transportation  charge  into 
MOCAS. 

If  the  invoice  is  for  more  than  the  amount  in  the  DB,  a  manual  payment 
is  always  generated.  Obviously  this  avoids  overpaying  the  contractor. 
It  also  prevents  the  payment  center  from  exceeding  the  buying 
activity's  obligation  authority. 

To  solve  the  modification  receipt-timing  problem,  get  the  contract 
modification  to  the  payment  center  on  a  timely  basis  at  about  the  time 
the  buying  command  creates  the  modification. 

The  transportation  charge  difficulty  can  be  partly  resolved  by  system 
changes  that  will  prompt  the  input  clerk  to  look  for  an  itemized  CBL 
charge  when  it  is  authorized.  As  a  result,  CBL  charges  that  would  have 
otherwise  been  overlooked,  would  instead  be  input,  and  would  not 


D-6 


trigger  manual  pays.  Those  invoices  having  CBL  charges  authorized  and 
included,  but  not  itemized  by  the  contractor,  will  still  cause  manual 

pays. 

B.  Alternatives 

1.  For  modification  receiot-timino  problem.  Getting  the 
modification  to  the  payment  center  rapidly  means  doing  it 
electronically.  There  are  two  approaches  for  electronic  transmission. 
Military  Standard  Contract  Administration  Procedures  (MILSCAP)  Contract 
Abstracts  could  be  enhanced,  or  other  automated  contracting  systems 
could  be  built  or  enhanced. 

a.  MILSCAP.  There  are  problems  with  MILSCAP  (See 
discussion  in  Appendix  J),  but  there  could  be  less  new  development 
work.  MILSCAP  was  designed  to  support  Contract  Management  and  Quality 
Assurance,  not  the  payment  function. 

(1)  Changes  since  the  early  1980's  provide  a  new 
groundwork  for  enabling  payment  prior  to  receipt  of  contract 
modification  hard  copy. 

(a)  Some  contract  provisions  previously  ware  not 
abstracted  (some  of  these  may  still  not  be): 

[1]  Objection  or  Possible  Risk:  Indicator  of 
Evidence  of  Shipment  (EOS)  clause  is  not  in  abstract. 

Evaluation:  While  the  EOS  clause  is  not  directly  included  in  MILSCAP 
contract  abstract  data,  its  applicability  can  be  derived  from  that 
data.  When  the  material  is  accepted  at  source,  but  the  Free  on  Board 
(FOB)  point  is  at  destination.  Federal  Acquisition  Regulation  (FAR) 
52.247-48  states  that  the  EOS  clause  applies.  Both  the  FOB  point  and 
the  acceptance  point  are  included  in  the  MILSCAP  abstract.  A 
computerized  check  on  these  two  data  elements  could  be  done  when  an 
abstract  transmission  is  received.  The  EOS  data  element  would  then  be 
set  accordingly  in  the  data  base. 

This  proposed  procedure  assumes  that  the  Procuring  Contracting  Officer 
(PCO)  properly  includes  this  clause  when  it  applies.  If  the  PCO  does 
not  include  the  clause  when  it  should  have  been  included,  and  the 
contractor  does  not  provide  evidence  of  shipment,  API  would  stop. 
However,  these  cases  could  be  easily  handled  by  checking  the  hard  copy 
contract  and  removing  the  EOS  flag.  Such  occurrences  should  be  very 
infrequent. 


[2]  Objection  or  Possible  Risk:  Indicator  of 
Certification  of  Invoice  Required  -  Administrative  Contracting  Officer 
(ACO),  Procuring  Contracting  Officer  (PCO),  U.S.  Department  of 
Agriculture  (USDA),  Auditor  or  Contractor  is  not  in  abstract. 
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Evaluation:  The  Certification  Required/ACO  and  PCO  messages  are  input 
when  the  contract  provides  for  them.  However,  these  messages  occur 
very  infrequently  (about  one  out  of  every  300  MAAPRs  has  one  or  the 
other).  ACOs  and  PCOs  may  be  using  this  message  when  they  want  the 
contract  reviewed  for  a  reason  that  is  not  listed.  Two  data  elements, 
each  one  character  in  length,  could  be  added  to  the  MILSCAP  list  of 
Special  Contract  Provisions. 

Certification  Required/Auditor  is  applicable  to  cost  contracts  and  is 
input  at  time  of  contract  input.  These  invoices  must  be  certified  by 
the  Defense  Contract  Audit  Agency  (DCAA) .  However,  the  message 
originates  when  the  contract  is  cost  type,  and  the  contract  type 
indicator  is  in  the  abstract. 

Certification  of  Invoice  Required/USDA  is  infrequent.  It  did  not  occur 
once  in  19,620  MAAPRs  in  the  sample.  None  of  the  personnel  interviewed 
had  ever  seen  the  message.  Certification  of  Invoice 
Required/Contractor  occurred  only  4  times  in  the  sample.  However, 
there  should  be  no  reason  why  a  contractor  should  have  to  certify  his 
own  invoice.  (Were  the  occurrences  input  errors?)  Unless  there  is  a 
strong  reason,  this  message  should  be  eliminated  from  MOCAS.  If  there 
is  a  valid,  but  very  rare,  condition  it  could  be  covered  by  Mandatory 
Review  Other  and  the  remarks  field.  This  might  be  the  way  it  would 
have  been  handled  anyway,  if  it  did  actually  arise. 

(3]  Objection  or  Possible  Risk:  Indicator  of 
Mandatory  Review  Required  -  Government  Furnished  Material,  Government 
Furnished  Property,  Lumber,  Steel  or  Textile  is  not  in  the  abstract. 

Evaluation:  Together  these  messages  occur  infrequently,  once  in  every 
95  MAAPR  reports.  MANDATORY  REVIEW/TEXTILE  did  not  appear  at  all. 
Mandatory  reviews  should  be  handled  the  same  way  as  certifications  of 
invoices.  In  other  words,  mandatory  reviews  for  lumber,  textile,  and 
steel  should  be  added  to  the  MILSCAP  list  of  Special  Contract 
Provisions . 


(b)  Objection  or  Possible  Risk:  There  is  a  five 
clause  limit  on  the  MILSCAP  abstract  Special  Contract  Provisions  field. 
As  a  result  a  number  of  clauses  in  the  contract  might  be  left  out  of 
MILSCAP. 

Evaluation:  There  are  currently  16  special  contract  provisions  in  a 
MILSCAP  contract  abstract  (MILSCAP  Manual,  Appendix  All).  However,  a 
limit  of  5  can  be  in  an  abstract.  Obviously,  many  contracts  have  more 
than  5  provisions.  The  Defense  Logistics  Standard  Systems  Office 
(DLSSO)  is  responsible  for  the  Modernization  of  Defense  Logistics 
Systems  (MODELS)  project.  MODELS  will  provide  a  translator  for  the 
military  standardization  systems:  Military  Standard  Requisitioning 
and  Issue  Procedure  (MILSTR1P),  Military  Standard  Transportation  and 
Movement  Procedure  (MILSTAMP),  and  Military  Standard  Transaction 
Reporting  and  Accounting  Procedure  (MILSTRAP),  as  well  as  MILSCAP. 
Transmissions  from  these  systems  will  be  converted  from  fixed  length 


records  to  variable  length  records  and  vice  versa.  This  translator  is 
complete  and  is  in  the  testing  stage  at  the  Logistics  Management 
Institute  (LMI). 

As  a  result,  the  limit  of  five  special  contract  provisions  per  abstract 
will  be  eliminated.  It  will  be  possible  to  include  all  provisions. 

(c)  Objection  or  Possible  Risk:  The  remittance 
address  (if  different  from  the  bid/offer  address),  progress  payment 
rates  and  progress  payment  liquidation  rates,  could  be  missing  from 
both  the  MILSCAP  contract  and  contract  modification  abstracts. 

Evaluation:  The  MILSCAP  contract  abstract  has  space  for  a  remittance 
address  that  is  different  from  the  bid/offer  address.  The  space  is  not 
used.  DLA  chose  not  to  use  it.  It  could  be  used  for  the  purpose 
mentioned  above,  which  was  probably  the  original  intent.  If  the 
remittance  address  changes,  a  MILSCAP  modification  could  be  used  to 
implement  the  change. 

Data  on  progress  payment  rates  and  progress  payment  liquidation  rates, 
could  be  added  to  MILSCAP  transmissions. 

(2)  Concerns  still  remain: 

(a)  Objection  or  Possible  Risk:  The  modification 
does  not  identify  the  clauses  in  the  contract. 

Evaluation:  The  clauses  are  in  MOCAS.  If  clauses  need  to  be  added  or 
deleted,  MILSCAP  can  do  it.  In  some  situations  the  changes  or 
enhancements  mentioned  above  are  necessary  to  do  this.  If  changes 
regarding  information  within  clauses  (such  as  First  Article  due  date  or 
Liquidated  Damages  rate  changes)  are  necessary,  MILSCAP  can  transmit 
the  data. 


(b)  Objection  or  Possible  Risk:  Better  validation 
is  needed.  Payment  centers  can  receive  MILSCAP  contracts  that  are  not 
signed. 

Evaluation:  A  single  character  data  element  could  be  added  to  the 
MILSCAP  contract  abstract  to  confirm  the  presence  of  a  signature  on  the 
original  contract  hard  copy.  This  will  help  the  buying  activity  assure 
that  only  modifications  with  signatures  are  transmitted. 

(c)  Objection  or  Possible  Risk:  Better  quality 

data  is  needed. 

Evaluation:  MILSCAP  is  widely  known  to  have  an  error  rate  that  is  high 
compared  to  a  level  that  would  be  acceptable  for  input  to  the  payment 
process.  The  data  is  bad  because  no  one  uses  it,  and  no  one  uses  it 
because  the  data  is  bad.  Decision  makers  have  15  years  of  bad 
experience  with  MILSCAP  upon  which  they  are  basing  judgments  not  to  use 
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However,  getting  usable  data  for  payment  from  a  contracting  DB  is 
doable.  The  (Standard  Automated  Materiel  Management  System) 

SAMMS/MOCAS  Standard  Interface,  which  will  use  electronic  transmissions 
without  hard  copy,  is  being  made  to  work  by  having  SAMMS  include  all 
the  elements  MOCAS  needs  to  pay. 

(3)  MILSCAP  Status.  Only  the  Army  currently  uses 
MILSCAP  to  transmit  complete  contract  abstracts  and  modification 
abstracts.  DLA,  the  Navy,  and  the  Air  Force  now  transmit  only  partial 
MILSCAP  abstracts  of  original  contracts.  This  is  partly  a  result  of 
deviations  to  MILSCAP  having  been  granted.  Also  they  transmit  very  few 
modifications  via  MILSCAP.  Each  of  these  organizations  has  systems 
development  work  underway  that  will  transmit  information,  identifying 
clauses  included  in  the  original  contract,  and  modification 
information.  These  efforts  are  scheduled  for  completion  as  follows: 

(a)  Contracting  Improvements  (DLA-DSAC)  -  9/91. 

This  target  date  has  remained  the  same  for  the  past  3  years. 

(b)  Inventory  Control  Point  (ICP)  Resystemization 
(Navy)  -  3/92.  This  will  allow  both  the  Aviation  Supply  Office  and 
Ships  Parts  Control  Center  to  transmit  MILSCAP  documents. 

(c)  Contract  Data  Management  System  (Air  Force)  - 
FY  95.  The  Air  Force  Systems  Command  (AFSC)  uses  complete  MILSCAP 
abstracts.  The  Air  Force  Logistics  Command  (AFLC)  does  not.  The 
project  completion  date  has  been  slipping.  The  effort  may  become  a 
target  for  budget  cutbacks. 

b.  Other  Automated  Contracting  Systems.  Another 
alternative  is  developing  new  systems  or  modifying  existing  systems. 
However,  the  cost  would  be  high,  it  would  probably  take  much  longer  to 
complete,  and  the  probability  of  not  successfully  completing  such 
efforts  would  be  high  compared  to  enhancing  MILSCAP. 

2.  For  transportation  charge  input  problem.  Verifying  whether 
or  not  the  invoice  should  have  an  itemized  CBL  transportation  charge 
means  checking  it  against  the  MOCAS  DB.  A  screening  capability, 
similar  to  the  one  proposed  for  comparing  the  MAAPR  amount  with  the 
invoice  amount,  should  be  incorporated  into  the  invoice  input  system. 

It  would  test  for  keypunch  error  (omitting  the  CBL  charge  line  item) 
simultaneously  with  the  initial  keypunching  input  of  the  invoice.  If 
after  initial  input  a  CBL  charge  was  not  input,  and  transportation 
charges  were  authorized  by  the  contract,  the  screen  would  give  a 
message  to  recheck  the  invoice  for  the  CBL  line  item,  and  input  it  if 
it  is  there.  Such  verification  avoids  errors.  The  onetime  cost  of 
changing  MOCAS  to  do  this  is  estimated  to  be  $2,500. 
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C.  Conclusion 


1.  Making  MILSCAP  abstracts  adequate  for  payment  will  have 
high  payoff.  And  this  alternative  could  be  available  soon.  To  modify 
MILSCAP,  to  make  the  contract  modification  abstracts  adequate  for 
payment,  DLA  would  have  to  work  jointly  with  the  Services.  OLA  is  not 
now  doing  this. 

To  take  advantage  of  MILSCAP  technology,  the  requirement  for  hard  copy 
of  modifications  must  be  eliminated.  The  requirement  for  hard  copy  has 
been  justified  by  the  previous  inadequacy  of  MILSCAP.  Implementation 
of  the  SAMMS/MOCAS  standard  interface  will  eliminate  the  requirement 
for  hard  copy  on  both  contract  award  and  modification.  This  will  set  a 
precedent  to  eliminate  requiring  hard  copy  documents  for  payment. 

Unless  hard  copy  requirements  are  eliminated,  where  justified,  it  will 
never  be  possible  to  truly  take  advantage  of  communications  and  EDI 
technological  advances. 

With  timely  receipt  of  information  there  would  be  significantly  fewer 
invoices  for  more  than  the  MAAPR  amount.  Twenty  percent  of  all  MAAPR 
messages  are  MAAPR-INV  S  NOT  EQUAL  with  the  contractor  invoicing  for 
more.  We  estimate  half  of  these  (10  percent),  are  due  to  the 
modification  not  being  received  at  the  payment  center  in  time.  As  a 
result,  manual  payments  would  be  cut  by  4.2  percent.  The  figure  is 
only  4.2  percent  because  invoices  often  trigger  more  than  one  MAAPR 
message.  The  potential  savings  would  be  24  payment  clerk  workyears. 
This  is  equivalent  to  $0.67  million  per  year,  including  fringe 
benefits,  after  DLA  begins  receiving  modifications  electronically.  In 
addition,  electronic  receipt  of  modification  information  would 
eliminate  the  need  for  manual  input.  DLA  payment  centers  devote  185 
workyears  to  inputting  contract  data.  The  savings  in  this  area  would 
be  the  52  percent  that,  on  average,  involve  modifications.  This 
amounts  to  96  input  clerk  workyears  equivalent  to  an  additional  $2.4 
million  per  year.  (See  Attachments  2  and  3  to  this  Appendix  for 
detail s . ) 

2.  Enhancing  MOCAS  so  that  input  clerks  can  check,  on-line, 
whether  an  invoice  should  have  an  itemized  CBL  will  have  excellent 
payoff.  Forty  six  percent  of  the  invoices  over  the  MAAPR  amount  have 
CBL  charges  authorized.  Fifty  five  percent  of  these  (25.3  percent  of 
those  above  the  MAAPR)  are  estimated  to  be  due  to  payment  clerks 
overlooking  to  input  a  properly  itemized  CBL.  (The  other  45  percent 
either  do  not  have  transportation  charges  or  are  due  to  the  contractor 
failing  to  itemize  the  CBL,  These  will  continue  to  be  manual  pays.) 
Fifty  six  percent  of  the  MAAPR-INV  $  NOT  EQUAL  messages  due  to  this 
condition  appear  alone.  As  a  result  8  workyears  would  be  saved.  (See 
Attachments  2  and  3  to  this  Appendix  for  details.) 

3.  Manual  MAAPRs  (when  the  invoice  amount  is  more  than  the 
MAAPR  amount)  that  have  both  the  modification  receipt-timing  and  CBI 
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charge  oversight  conditions,  but  only  these  conditions,  will  also  be 
eliminated.  As  a  result  an  additional  8  workyears  would  be  saved. 
(See  Attachments  2  and  3  to  this  Appendix  for  details.) 


IV.  OVERALL  CONCLUSIONS 


A.  Estimated  Savinas: 


Compensation 
Work-  Incl  Benefits 

Area  years  IS  millions! 


Savlnus  from  Cutting  Manual  Pays: 

Invoice  Less  than  MAAPR  Amount- 
Payment  clerks  34 


0.94 


Invoice  More  than  MAAPR  Amount- 
Payment  clerks 

Mod  receipt-timing  related  24  0.67 
CBL  charge  overlooked  8  0.22 
Mod  receipt-timing  &  CBL  related  8  0.22 


Savings  from  Cutting  Input  Effort: 

Input  clerks  (GS-5,  Step  5)  _96  2.39 

Total  170  4.44 


See  details  in  Attachment  3  to  this  Appendix.  Savings  of  170  workyears 
is  about  7.4  percent  of  the  payment  processing  workforce  (not  including 
Payroll  &  Travel).  It  can  be  achieved  by: 

1.  automatically  processing  invoices  less  than  the  MAAPR 

amount , 

2.  automatically  inputting  contract  modifications  using 
MILSCAP,  and 

3.  checking,  on-line,  for  the  presence  of  an  itemized  CBL 
charge  when  such  charges  are  authorized. 

Since  MAAPR  reports  can  have  more  than  one  message  causing  a  manual 
pay,  additional  savings  from  this  change  will  be  realized  if  the 
frequency  of  other  MAAPR  messages  is  reduced. 

B.  Changing  MILSCAP  could  also  enable  electronic  input  of  original 
(vs.  modification)  contract  information.  This  would  save  an  additional 
89  workyears  for  a  total  savings  of  259  workyears. 

C.  The  time  ha'  come  for  timely,  electronic  receipt  of 
modification  information  usable  for  payment.  There  are  no  longer  any 
really  good  reasons  not  to  transmit  contract  information  required  for 
payment  electronically  using  MILSCAP. 
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V.  RECOMMENDATIONS 


A.  Contractor  Invoices  for  Less  than  MAAPR  Amount: 


1.  Change  MOCAS  so  that  the  keypunched  invoice  amount  can  be 
compared,  on-line,  to  the  MAAPR  amount.  (In  this  case  the  contractor 
is  really  invoicing  for  the  correct  amount  but  it  was  incorrectly 
keypunched  as  less.)  This  change,  if  necessary,  would  be  incorporated 
into  MOCAS  with  the  Contract  Payment  and  Reporting  (CPR)  System  that 
DLA  Systems  Automation  Center  (DSAC)  is  now  working  on.  The  change  is 
significant,  as  it  will  allow  on-line  access  to  the  DB.  This  w'll 
require  substantial  programming  effort.  However,  if  this  is  the  only 
significant  objection  to  paying  API  when  the  contractor  invoices  for 
less  than  the  MAAPR,  then  the  systems  change  should  be  done  separately, 
now,  rather  than  waiting  further  for  CPR,  even  if  the  effort  is  partly 
duplicated.  This  is  because  all  of  the  payoff  from  using  API,  when 
contractors  invoice  for  less,  will  be  lost  without  it.  Furthermore, 
research  shows  that  no  significant  work  will  be  added  to  the 
reconciliation  process.  There  will  be  no  difference  in  the  number  of 
contracts  to  be  reconciled. 

2.  Change  MOCAS  so  that  if  the  contractor  invoices  for  less 
than  the  corresponding  MOCAS  amount,  the  invoice  is  paid  automatically 
(API)  rather  than  manually. 

The  payoff  for  these  changes  is  $0.94  million  per  year. 

B.  Contractor  Invoices  for  More  than  MAAPR  Amount: 

1.  Modify  MOCAS  so  that  input  clerks  can  easily  check  if  an 
invoice  should  have  an  itemized  CBl  by  providing  an  on-screen  message 
that  shows  when  CBL  charges  are  authorized.  The  payback  ratio  for  this 
is  very  large  because  the  onetime  cost  of  the  systems  change  is  only 
$2,500. 


2.  Make  MILSCAP  contract  and  modification  abstracts  suitable 
for  payment.  Provide  DLA  input  to  DoD  MILSCAP  enhancement  efforts. 

a.  Initiate  a  single  DLA  effort  to  see  that  the  Navy  and 
Air  Force  MILSCAP  development  efforts  continue  expeditiously  and  are 
successfully  completed.  See  that  they  add  all  information  needed  for 
payment  and  data  validation.  This  data  is  identified  in  paragraph 

III  B  1  a  above.  The  enhancement,  involving  adding  elements,  and  using 
MODELS  is  straightforward. 

b.  Request  an  Army  systems  development  effort  to  upgrade 
MILSCAP  contract  and  contract  modification  abstract  data  so  that  it  can 
be  used  for  payment. 

3.  Promote  to  DLA  and  Armed  Services  management,  the  important 
benefits  that  would  result  from  successful  development  of  the 
capability  to  electronically  transmit  modifications.  Justify  the 
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appropriate  project  priority.  Getting  the  Services  to  successfully 
complete  this  specific  programming  task,  especially  the  Air  Force, 
means  saving  96  workyears  in  the  payment  centers.  If  original  contract 
information  can  also  be  transmitted  and  used,  it  means  nearly  double 
that  amount. 

4.  Eliminate  the  hard  copy  requirement  for  payment  on 
modifications. 

C.  For  all  Contracts:  Change  MILSCAP  to  enable  electronic  input 
of  original  (vs.  modification)  contract  information. 
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Attachment  1 


Percentage  of  Time  MAAPR  Message  Appears  On  A  MAAPR  Report 
(That  Causes  A  Manual  Pay) 

(Based  on  2  Week  Sample  of  All  DCMC  Manual  Pays) 


* 


Percent 


on  a  report 


1. 

MAAPR- INV  $  NOT  EQUAL 

29.8 

2. 

EVIDENCE  OF  SHIPMENT  REQUIRED 

12.7 

3. 

MANDATORY  REVIEW/OTHER 

SPECIAL  '9'  ACRN 

11.6 

4. 

9.5 

5. 

EXCEEDS  BVN  LIMIT 

9.3 

6. 

CLR/WIP  BALANCE 

6.6 

7. 

WITHHOLD 

6.3 

8. 

VO  DEDUCTION  PENDING 

3.9 

9. 

FIRST  ARTICLE  APPROVAL  REQUIRED 

3.6 

10. 

CLR/ACRN  BALANCE 

3.5 

44  Other  Messages  Make  Up  the  Rest 

* 

not 

total  100  percent  -  Percentages  are 

of  times  message  is 

1.  $  on  the  MAAPR  and  invoice  are  not  equal  (except  if  MAAPR  amount 

is  greater  than  the  invoice  by  $10  or  less  -  in  which  case  invoice 
is  paid  automatically). 


2.  Evidence  of  Shipment  (EOS)  Required  clause  is  in  contract  -  but 
EOS  is  not  provided  with  invoice. 

3.  DCMC  flags  contract  for  manual  rc>  lew  for  various  reasons.  Also 
established  automatically  (for  Awaiting  Hard  Copy)  when  MILSCAP 
abstract  is  received  in  MOCA". 


4.  MAAPR  contains  line  items  for  which  there  are  multiple  Accounting 
Classification  Reference  Numbers  (ACRN). 

5.  Bureau  Voucher  Notice  invoice  (cost  type  contracts)  after  payment, 
would  exceed  85  percent  of  obligated  amount. 

6.  Insufficient  funds  on  Contingent  Liability  Report  (CLR)  for  Work 
in  Progress. 

7.  Withholding  Charges  clause  in  contract. 

8.  Credit  memo  or  Accounts  Receivable  Record  exists  on  Invoice  File. 

9.  First  Article  clause  in  contract  and  First  Article  Test  has  not 
yet  been  completed. 

10.  Insufficient  funds  for  payment  exist  at  the  ACRN  level  on  the  CLR. 
Also  occurs  when  the  whole  dollar  discount  amount  is  equal  to  or 
greater  than  the  invoice  amount. 
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Attachment  2 

Percent  Occurrence  of  Causes  of 
MAAPR  INV  $  NOT  EQUAL  Message 
When  Invoice  is  Above  MAAPR  Amount 


Percent  or  all  manual  messages  that  the  MAAPR  is: 

MAAPR  INV  $  NOT  EQUAL  Message  and  the  invoice  is 

above  the  MAAPR  amount  (1)  =20.1% 

Percent  cause  is  mod  receipt-timing  problem 

out  of  the  'NOT  EQUAL'  messages  that  are  above 

the  MAAPR  amount  (2)  -  50% 

Percent  cause  is  overlooking  to  input  a  CBL 

transportation  charge  itemized  on  the  invoice 

out  of  the  'NOT  EQUAL'  messages  that  are  above 

the  MAAPR  amount  (I)  =25.3% 


Probability  that  no  other  manual  messages  appear 

when  either  of  these  two  conditions  exist  (1)  =  56.2% 

Notes: 

1.  Estimated  from  sample. 

2.  Estimated  by  payment  personnel. 


A.  The  percent  of  time  that  a  manual  MAAPR  is  caused  by  either  a 
timing  problem  or  a  CBL  transportation  charge  problem,  or  both,  is 
calculated  from  the  4  probabilities  above  as  follows: 

20.1%  X  56.2%  X  (1  -  (1  -  0. 5) ( 1  -  0.253))  =  7.08% 

The  notation  (1  -  0.5)  is  the  probability  (50  percent)  that  the  message 
is  NOT  the  result  of  a  timing  problem  and  (1  -  0.253)  is  the 
probability  (74.7  percent)  that  it  is  NOT  a  problem  of  overlooking  a 
line  item  CBL  transportation  charge. 

This  7.08  percent  is  made-up  as  follows: 

1.  The  percent  of  time  that  the  message  is  caused  ONLY  by  a 
modification  receipt-timing  problem  is: 

20.1%  X  56.2%  X  50%  X  (1  -  0.253)  =  4.22% 

2.  The  percent  of  time  that  the  message  is  caused  ONLY  by  a  CBL 
transportation  charge  problem  is: 

20.1%  X  56.2%  X  25.3%  X  (1  -  0.5)  =  1.43% 
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3.  The  percent  of  time  that  the  message  is  caused  by  BOTH  problems 
is: 

20.1%  X  56.2%  X  50%  X  25.3%  =  1.43% 

B.  The  percent  of  time  that  the  message  is  caused  by  NEITHER  problem 
(other  problems  cause  the  message)  is: 

20.1%  X  56.2%  X  (1  -  0.5) (1  -  0.253)  =  4.22% 

C.  The  percentages  in  A  and  B  above  total  11.3  percent.  The  remaining 
8.7  percent  of  the  20  percent  of  the  manual  messages  (that  occur  when 
the  invoice  is  more  than  the  MAAPR)  have  another  manual  payment  message 
in  addition  to  one  or  both  of  the  conditions  considered  here. 
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Attachment  3 
Estimated  Savings 


Cause  of  Manual  Pay 

Percent 

Occur¬ 

rence 

. Savings - 

Work-  Dollars 

years(l)  Million 

Invoice  Less  Than  MAAPR(2) 

5.83 

34 

0.94 

Mod  Receipt-Timing(2) 

4.22 

24 

0.67 

Overlook  CBL  Charge(2) 

1.43 

8 

0.22 

Mod  Receipt-Timing 
&  Overlook  CBL  Charge 

1.43 

_8 

0.22 

12.91  74  2.05 


Notes : 

1.  There  are  577  manual  pay  workyears. 

2.  MAAPR  reports  where  the  message  appears  alone 
and  is  the  sole  cause  of  the  manual  pay. 


Contract  data  input  is  185  workyears-  8%  of  2,309. 

52%-  96  workyears  is  for  contract  modifications 
48%-  89  workyears  is  for  original  contracts 

Total  savings:  74  +  96  =  170 

170  =  7.4%  of  payment  processing  workforce, 

2,309  not  including  Payroll  &  Travel. 
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I.  INTRODUCTION 

When  the  Free  On  Board  (FOB)  point  is  at  Destination,  but  Inspection 
and  Acceptance  are  both  at  Origin,  the  contracting  officer  inserts 
Federal  Acquisition  Regulation  (FAR)  clause  52.247-48  in  the  contract. 
This  clause  requires  that  specified  Evidence  of  Shipment  (EOS)  be 
furnished  in  support  of  the  contractor's  invoice.  Defense  Logisitics 
Agency  Manual  (DLAM)  7000.5,  Contract  Administration  Services 
Accounting  Procedures,  Part  7,  Chapter  1,  requires  that  DLA  pay  these 
invoices  only  after  receipt  of  the  proper  EOS.  Since  payment  can  be 
made  once  the  material  is  inspected  and  accepted,  this  clause  is 
designed  to  prevent  DLA  from  paying  invoices  for  material  that  has  not 
been  shipped. 

When  EOS  is  not  furnished  as  required,  the  invoice  is  handled  manually, 
until  the  EOS  is  received.  Depending  on  the  circumstances,  after  the 
EOS  is  furnished  the  invoice  is  recycled  or  reinput  as  a  new  invoice. 

It  is  then  paid  using  the  Automatic  Payment  of  Invoices  (API)  system. 
Therefore,  manually  handling  an  invoice  that  lacks  EOS  is  not  a  true 
manual  payment.  It  does  not  require  the  completion  of  DLA  Form  477, 
Advice  of  Payment.  It  does,  however,  involve  more  manual  effort  than 
if  the  invoice  was  paid  using  the  API  system. 

Since  it  is  desirable  to  maximize  the  use  of  the  API  system,  this 
cost-benefit  analysis  evaluates  alternative  courses  of  action  for 
situations  requiring  the  EOS  clause  in  its  current  form.  Where 
required  for  comparison  purposes,  methodologies  are  developed  to 
measure  elements  of  the  various  alternatives. 


II.  METHODOLOGY 


Four  costs  were  identified  as  relevant  to  the  study.  Methodologies 
were  developed  to  compute  these  costs  as  follows: 

A.  Cost  to  Manually  Handle  Invoices.  The  additional  manual  effort 
to  handle  invoices  when  the  EOS  is  not  furnished  with  the  original 
invoice.  This  was  calculated  by  comparing  the  following  steps  to 
similar  actions  in  existing,  comparable  Defense  Integrated  Management 
Engineering  System  (DIMES)  Special  Purpose  Data  (SPD)  standards: 

1.  Review  invoice  packet  to  determine  if  EOS  was  overlooked 
and  is  actually  attached  to  the  invoice  -  .0126  hours. 


2. 

required  by 


Review  the  actual  contract  to  verify  that  the  EOS 
contract  -  .0916  hours. 


clause  is 


3. 

recycle  the 


Correct  the  data  base  for  either  of  the  above  two 
invoice  through  Invoice  Control  -  .2735  hours. 


steps  and 
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4.  Return  the  invoice  requesting  the  contractor  furnish  us 
with  the  necessary  EOS.  When  this  is  received,  the  invoice  is  reinput 
as  a  new  invoice  -  .1465  hours. 

The  last  three  steps  do  not  happen  with  each  manual  Material  Acceptance 
and  Accounts  Payable  Report  (MAAPR),  therefore  a  frequency  is  used  to 
adjust  for  total  time  to  process  EOS  invoices  manually.  The  total  time 
(in  hours)  is  multiplied  by  the  average  hourly  salary  of  the  person 
doing  the  work.  The  final  cost  figure  incorporates  factors  for  fringe 
benefits  and  leave.  Both  the  frequencies  and  average  grade  figures  are 
estimates  provided  by  personnel  from  various  payment  centers. 

The  point  of  count  for  this  calculation  is  the  number  of  manual  MAAPRs 
generated  with  the  EVIDENCE  OF  SHIPMENT  REQUIRED  message.  Of  those 
MAAPR  messages  which  cause  manual  payments  (See  Appendix  B),  EVIDENCE 
OF  SHIPMENT  REQUIRED  was  on  almost  13  percent  of  the  manual  pays.  It 
was  the  only  message  stopping  API  almost  7  percent  of  the  time. 

B.  Contractor  Administrative  Charges.  The  cost  the  contractor 
charges  us  to  administer  this  clause  was  considered  negligible.  The 
only  exception  is  Alternative  9  (Require  Acceptance  at  Destination  when 
FOB  is  Destination)  which  is  discussed  further  in  paragraph  IV  A  1 
below. 

C.  Cost  of  FAR  Change.  The  cost  of  making  a  change  to  the  FAR  was 
estimated  using  input  from  the  DLA  Defense  Acquisition  Regulation  (DAR) 
Council  Policy  Member.  The  calculation  is  in  Attachment  1  to  this 
Appendix. 

D.  Missing  Shipment  Costs.  This  is  the  cost  of  the  risk  the 
government  assumes  by  changing  or  eliminating  the  EOS  clause.  This  is 
the  value  of  material  that  will  not  be  received  if  the  current  clause 
is  changed  or  eliminated.  This  is  not  readily  quantifiable,  but  will 
be  expressed  in  relative  terms  by  comparing  each  alternative  to  the 
status  quo.  In  some  cases  it  will  be  readily  apparent  that  this  cost 
would  be  offset  by  savings.  In  other  cases,  the  cost  of  the  missing 
shipment  will  be  so  high  or  low  compared  to  the  cost  offset  (or  saved) 
by  it,  that  the  best  alternative  will  be  obvious. 


HI.  ALTERNATIVES  STUDIED 

The  criteria  for  choosing  the  best  alternative  was  least  cost. 

However,  if  the  alternative  does  not  enable  DLA  to  meet  its  mission  of 
ensuring  delivery,  it  will  not  be  considered  viable.  We  studied  nine 
alternatives,  described  briefly  below.  See  Attachment  2  to  this 
Appendix  for  details  on  each  alternative. 

The  alternatives  ranged  from  the  status  quo  to  modifying  or  eliminating 
the  FAR  clause.  We  examined  combinations  of  the  following:  paying 
upon  acceptance  at  Source,  requiring  contractor  to  keep  EOS  on  file, 
excluding  parcel  post  and/or  common  carrier  shipments  from  EOS 
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requirement,  allowing  only  acceptance  at  Destination  when  FOB  is 
Destination  and  requiring  EOS  only  for  shipments  over  a  specified 
dollar  value  threshold. 


IV.  ANALYSIS 

A.  Costs  and  Benefits  of  the  Alternatives.  Details  of  the  costs 
of  each  alternative  are  in  Attachment  2  to  this  Appendix.  Using  these 
costs,  each  alternative  is  compared  to  the  status  quo.  Details  of  this 
analysis  are  contained  in  Attachment  3  to  this  Appendix. 

There  are  intangible  benefits  to  the  current  EOS  clause.  It  is  an 
internal  control  check  on  the  payment  system  to  pay  only  with 
reasonable  assurance  that  the  material  is  shipped.  Although  there  are 
some  concerns  that  our  current  EOS  requirements  do  not  actually  prove 
what  the  contractor  shipped,  it  provides  traceability.  From  a  legal 
standpoint,  a  signed  EOS  by  the  contractor  makes  it  easier  for  the 
government  to  prove  failure  to  ship. 


B.  Review  of  Invoice  Input  Process.  Payment  personnel  estimate 
that  60  percent  of  the  EOSs  thought  to  be  missing  are  found  later  in 
the  original  invoice  packet  by  the  payment  people.  The  primary  reason 
so  many  EOSs  are  overlooked  Is  because  they  are  not  required  on  all 
invoices.  Therefore,  invoice  input  personnel  do  not  spend  a  lot  of 
time  looking  since  EOS  is  not  always  required.  The  natural  tendency  is 
to  not  look  thoroughly  because  EOS  Is  required  only  25  percent  of  the 
time. 

A  simple  solution  to  this  problem  is  to  indicate  on-line,  in  the 
Mechanization  of  Contract  Administration  Services  (MOCAS)  system, 
whether  EOS  is  required  or  not.  If  the  invoice  input  person  sees  the 
message  that  EOS  is  required,  they  know  their  efforts  to  find  an  EOS 
will  not  be  in  vain.  The  invoice  input  process  already  accesses  the 
file  in  which  the  EOS  Required  indicator  resides.  The  change  would 
then  only  be  a  matter  of  retrieving  the  information  and  generating  a 
message  on  the  screen. 

This  simple  systems  change  would  eliminate  nearly  60  percent  of  the 
MAAPRs  that  are  manual  only  because  of  the  EVIDENCE  OF  SHIPMENT 
REQUIRED  message.  From  our  sample,  this  is  estimated  to  be  33,000 
MAAPRs  a  year  (60  percent  of  the  6.9  percent  of  all  MAAPRs  with  only 
EOS  stopping  API  or  4.14  percent  of  all  manual  MAAPRs).  Because  this 
change  would  eliminate  the  need  for  these  MAAPRs  to  be  manually  handled 
at  all,  to  compute  the  related  savings,  the  steps  and  frequencies  used 
in  Attachment  2  are  changed.  Only  steps  1  (review  the  invoice  packet) 
and  3  (correct  data  and  recycle)  are  avoided.  However,  because  they 
are  avoided  on  all  of  the  MAAPRs  being  eliminated,  the  frequency  for 
these  steps  is  1.  Therefore,  the  cost  of  each  MAAPR  avoided  by  making 
this  change  is  $4.50.  The  yearly  savings  for  this  change  is  estimated 
at  nearly  $150,000.  The  DLA  Systems  Automation  Center  (DSAC) 


estimates  a  onetime  cost  for  this  systems  change  would  be  a  about 
$2,500.  Therefore,  there  is  a  net  savings  of  over  $146,000  the  first 
year  and  almost  $149,000  each  succeeding  year.  This  minor  systems 
change  is  considered  to  be  separate  from  the  above  alternatives  because 
it  should  be  done  regardless  of  which  alternative  is  chosen. 


V.  CONCLUSIONS 

A.  Retain  Current  EOS  FAR  Clause.  Since  the  manual  handling  of 
EOS  MAAPRs  is  not  highly  labor  intensive,  it  does  not  take  a  lot  to 
make  the  alternatives  more  expensive  than  the  status  quo.  Missing 
shipments  totalling  under  $260,000,  throughout  the  Defense  Contract 
Management  Command  (DCMC)  in  one  year,  would  make  any  of  the 
alternatives  more  costly  than  the  status  quo. 

Because  of  the  risk  the  government  is  subjected  to,  the  status  quo  is 
economically  feasible  for  the  EOS  clause.  The  savings  generated  from 
the  alternatives  would  be  easily  overwhelmed  by  the  financial  cost  and 
mission  impact  of  missing  shipments.  The  intangible  benefits  should 
not  be  overlooked.  It  is  just  not  that  expensive  to  process  these 
manually  compared  to  the  assurances  we  receive  that  the  material  is 
shipped.  If  we  do  not  get  material  when  we  ask  for  an  EOS,  it  is  more 
likely  to  be  a  shipper's  mistake  or  fraud,  for  which  we  have  recourse 
to  compensation.  If  it  is  fraud,  the  signed  EOS  makes  it  easier  for 
DLA  to  prove  its  case. 

B.  MOCAS  Change  Needed  for  Invoice  Input.  A  change  is  needed  in 
the  invoice  input  process  for  contracts  containing  the  EOS  clause.  To 
assure  that  invoice  input  personnel  look  for  the  EOS  only  when  it  is 
necessary,  MOCAS  should  be  changed  to  indicate  on-line  when  EOS  is 
required.  If  invoice  input  personnel  see  the  message  that  EOS  is 
required,  they  will  search  more  diligently  for  an  EOS.  There  would  be 
a  net  savings  of  over  $146,000  the  first  year  and  almost  $149,000  each 
succeeding  year.  This  change  is  not  part  of  the  alternatives  studied 
above  because  it  is  important  to  make  this  change  whether  the  status 
quo  is  changed  or  not. 


VI.  BBQmEHPATIQNS 

A.  Provisions  of  the  EOS  clause  should  remain  unchanged.  Manual 
handling  savings  generated  by  changing  the  clause  are  anticipated  to  be 
small  In  comparison  to  the  risk  of  undelivered  goods  for  which  the 
government  has  already  paid. 

B.  Change  MOCAS  to  alert  input  personnel  to  the  presence  of  the 
EOS  clause  as  the  invoice  is  being  input.  The  invoice  package  will  be 
thoroughly  searched  for  EOS  only  when  required.  Inputting  EOSs  upon 
original  Invoice  input  that  have  previously  been  overlooked  could  save 
over  $146,000  the  first  year  and  almost  $149,000  each  succeeding  year. 
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Attachment  1 


Cost  to  Change  the 

FAR 

GRADE 

#  PERS  HRLY  RT  *  # 

HRS 

COST 

SES 

1  61.64 

2 

$123.28 

GS-15 

li  52.90 

2 

$1,163.80 

GS-14 

2  44.97 

40 

$3,597.60 

GS-13 

3  38.05 

40 

$4,566.00 

FED  REG  -TWICE 

$900.00 

TOTAL 

$10,350.68 

*  Step  5  of  the  Grade,  includes  factors  for 
leave  and  training  (22%)  and  fringe  benefits 
(29.55%). 
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Costs  of  Alternatives 


Attachment  3 

Comparison  of  Alternatives 


1.  The  drawbacks  to  Alternatives  2  (eliminate  the  clause  and  pay  API 
upon  Acceptance  at  Source)  and  3  (keep  the  clause,  require  EOS,  but  pay 
API  upon  Acceptance  at  Source)  are  there  is  virtually  no  protection  for 
missing  shipments.  These  alternatives  are  up  to  $260,000  cheaper  than 
the  status  quo,  but  contractors  would  be  paid  for  all  material  without 
any  assurance  that  it  has  been  shipped. 

2.  Alternative  4  (enforce  that  contractor  keep  EOS  on  file,  pay  on 
acceptance  at  Source)  would  eliminate  all  manual  handling  required  by 
the  status  quo.  The  protection  against  missing  shipments  is  not  as 
good  as  the  status  quo,  but  better  than  Alternative  3  (keeping  current 
clause,  but  use  API  upon  Acceptance  at  Source).  Since  a  FAR  clause  is 
required  for  this  alternative,  the  estimated  savings  is  less  than 
$250,000.  The  risk  of  the  government  not  receiving  shipments  is  not 
worth  this  difference. 

3.  Alternatives  5  through  8  varied  the  types  of  shipments  needing  EOS. 
The  costs  of  manually  handling  invoices  decreased  as  the  requirement 
for  EOS  was  removed  from  certain  shipments.  However,  the  risk  of  not 
receiving  shipments  increased  with  the  types  of  shipments  excluded  from 
requiring  EOS.  All  these  alternatives  need  a  FAR  change  to  be 
implemented.  Therefore,  the  maximum  possible  savings  (due  to  not 
needing  EOS  on  as  many  sh'-vnents),  less  the  cost  of  the  FAR  change,  is 
$250,000.  The  savings  will  not  nearly  reach  this  maximum  for  any  one 
of  these  alternatives.  (The  cost  of  manual  handling  and  possibly 
missing  shipments  are  both  greater  than  0.  Therefore,  the  alternatives 
are  less  than  $250,000  cheaper  than  the  status  quo.)  Since  the 
possible  savings  are  even  less  than  those  in  Alternative  4,  the 
conclusion  is  the  same.  The  risk  of  the  government  not  receiving 
shipments  is  not  worth  this  difference. 

4.  Alternative  9  (if  FOB  is  Destination,  require  Acceptance  at 
Destination)  contains  no  risk  that  the  contractor  will  not  ship, 
similar  to  the  status  quo.  However,  the  administrative  costs  of 
Alternative  9  are  greater  than  the  cost  to  manually  handle  invoices 
needing  EOS.  the  percent  of  contracts  on-hand  that  have  the  EOS  clause 
is  nearly  25  percent.  DLA-wide  this  would  be  over  90,000  contracts.  A 
charge  of  even  $3  per  contract  (which  is  inconceivable  due  to  the 
additional  costs  a  contractor  incurs  with  Destination  Acceptance)  would 
make  this  alternative  more  expensive  than  the  status  quo. 
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I. 


INTRODUCTION 


The  Mandatory  Review/Other  (MRO)  message  is  a  catchall,  used  when  It  Is 
necessary  to  stop  Automatic  Payment  of  Invoices  (API)  for  a  reason  not 
covered  by  any  other  message.  To  generate  the  message  (and  stop  API), 
payment  personnel  input  (with  one  exception  described  below)  a  "9"  in 
the  data  field  RVU-CONTRS  (Mandatory  Review  Code)  on  the  provisions 
data  screen.  There  should  be  an  accompanying  remark  (describing  what 
"other"  means)  in  the  R5  or  R7  remarks  blocks  describing  why  the  "9" 
has  been  input  to  stop  API.  In  all  cases,  Including  the  exception,  the 
"9"  must  be  removed  manually  to  restore  API,  when  the  conditions 
requiring  manual  pay  no  longer  exist. 

The  exception  is:  MRO  Is  automatically  established  when  the  indicator 
generating  the  AWAITING  HARD  COPY  RECEIPT  (AHCR)  message  is  established 
for  Military  Standard  Contract  Administration  Procedures  (MILSCAP) 
generated  contract  and  contract  modification  data.  The  "9"  is 
transmitted  in  the  RVU-CONTRS  block  as  part  of  MILSCAP  transactions, 
both  contracts  and  modifications.  The  AHCR  indicator  stops  API  until 
the  hard  copy  document  is  received.  This  indicator  also  serves  another 
purpose;  it  triggers  messages  to  the  Buying  Activity  requesting  the 
hard  copy  document.  When  the  AHCR  indicator  is  manually  removed  in  the 
Mechanization  of  Contract  Administration  Services  (MOCAS)  system,  it 
stops  the  requests  to  the  Buying  Activity  and  allows  API  to  resume. 

The  purpose  of  the  MRO  indicator  in  this  case  is  to  block  this 
resumption  of  API  until  after  the  hard  copy  document  has  been  reviewed. 
Like  any  other  MRO,  however,  it  stops  API  until  the  "9"  Is  removed 
manually  from  the  RVU-CONTRS  block. 

Among  other  valid  reasons  to  use  the  MRO  message  to  stop  API  are: 
demand  letters,  terminations,  cancellations,  and  duplicate  payments. 


II.  ANALYSIS 


A.  Data.  Of  those  Material  Acceptance  and  Accounts  Payable  Report 
(MAAPR)  messages  which  cause  manual  payments,  (see  Appendix  B  for 
details),  MANOATORY  REVIEW/OTHER  occurred  third  most  frequently  -  in 
about  12  percent  of  the  manual  pays  (2,274  out  of  19,620).  Nearly  half 
of  the  times  this  message  is  on  a  MAAPR  it  is  the  only  message  stopping 
API  (almost  6  percent  of  the  total  number  of  MAAPRs  in  our  sample  - 
1,129  out  of  19,620). 

B.  Occurrence  with  Other  Messages.  Looking  at  the  other  messages 
that  occur  with  MRO,  no  unusual  relationships  were  apparent.  Five  of 
the  clauses  that  appeared  on  MAAPRs  with  MRO  are  the  type  that  may  be 
resolved  during  the  life  of  a  contract.  These  five  are:  AWAITING  HARD 
COPY  RECEIPT,  FIRST  ARTICLE  APPROVAL  REQUIRED,  INV/MAAPR  AMT  ZERO,  VO 
DEDUCTION  PENDING,  and  MAAPR-INV  S  NOT  EQUAL.  Where  any  combination  of 
these  clauses  are  the  only  other  clauses  stopping  API  (besides  MRO), 

MRO  may  become  the  only  message  stopping  API  (when  the  other  conditions 
are  resolved).  MAAPRs  with  MRO  and  any  combination  of  these  five 
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clauses  account  for  up  to  four  percent  of  all  MAAPRs  in  cur  sample. 

All  the  other  messages  are  for  the  life  of  the  contract,  barring  a 
contract  change  deleting  the  condition. 

C.  Findings .  Intuitively,  considering  that  the  MRO  message  is  a 
catchall,  to  be  used  when  no  other  message  is  appropriate,  the 
frequency  with  which  it  occurs  in  our  sample  seems  extremely  high.  This 
was  verified  in  conversations  with  payment  personnel.  Their  experience 
was  that  the  "9"  remains  in  the  RVU-CONTRS  block  after  the  condition 
requiring  that  API  be  stopped  has  been  resolved.  The  specific  case 
that  seems  to  cause  the  most  problems  is  when  MRO  is  automatically 
generated  at  the  same  time  the  AHCR  is  established.  Since  the  "9"  is 
automatically  established  in  the  data  base  for  MIL SCAP  contracts  and 
modifications,  there  are  no  entries  in  the  R5  and  R7  Remarks.  In  this 
case,  if  the  "9''  is  not  removed  when  the  hard  copy  is  reviewed  and 
changes  made,  there  will  be  no  way  for  a  payment  clerk  to  know  why  the 
MRO  exists  (no  R5  ar.d  R7  Remarks  are  necessary).  In  all  cases  with 
MRO,  if  the  remarks  blocks  are  not  adequately  completed,  the  person 
paying  the  invoice  probably  does  not  know  why  the  MRO  message  is  being 
generated.  He/she  is  usually  unwilling  to  remove  the  "9"  causing  the 
MRO  when  they  do  not  know  why  it  is  there.  The  MRO  continues  to  stop 
API,  in  this  case  unnecessarily. 

The  R5  and  R7  Remarks  are  in  the  contract  data  base  and  do  not  appear 
on  the  manual  MAAPR.  We  looked  at  the  contract  data  base  of  one  of  the 
former  Defense  Contract  Administration  Services  Regions  (DCASRs)  for 
contracts  where  the  Mandatory  Review  indicator  was  "9"  (Other)  and  the 
Hard  Copy  had  been  received.  Only  13  percent  of  these  contracts  had  R5 
and  R7  remarks  that  indicated  they  should  really  be  in  the  catchall, 
MRO.  Over  55  percent  of  these  contracts  had  either  no  entries  in  the 
R5  and  R7  blocks,  or  the  entries  did  not  Indicate  a  reason  for  stopping 
API.  Among  the  remarks  found  frequently  In  our  analysis  that  do  not 
affect  manual  payment  were:  MILSTRIP  (Military  Standard  Requisitioning 
and  Issue  Procedure),  NON-MILSTRIP,  FIN  PAY  NLA  ISSUED  (contract  no 
longer  active  due  to  final  payment).  If  the  "9"  was  not  in  the  data 
base  for  these  contracts,  all  Invoices  against  these  contracts  would  go 
API  (if  all  other  MOCAS  validations  were  passed). 

Another  finding  is  that  MRO  is  being  used  when  another  message  may  be 
more  appropriate.  Keeping  in  mind  that  MRO  is  a  catchall  message  (its 
disadvantage  Is  that  payment  clerks  do  not  readily  know  why  API  Is 
stopped),  this  would  be  an  improper  use  of  the  message.  Among  the 
messages  that  MRO  was  used  in  place  of  were:  WITHHOLD,  PATENT  ROYALTY, 
VO  DEDUCTION  PENDING  (for  lump  sum  decreases  -  see  Appendix  G  for 
details).  Of  the  contracts  with  entries  in  either  the  R5  or  R7  block, 
the  remarks  indicated  another  message  (other  than  MRO)  would  have  been 
appropriate  36  percent  of  the  time.  This  is  21  percent  of  all  the 
contracts  we  reviewed.  All  but  a  few  of  these  (less  than  20  contracts) 
were  for  the  five  messages  discussed  in  paragraph  II  B  above. 
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D.  Alternatives.  The  analysis  Identified  three  areas  that  could 
reduce  the  number  of  MAAPRs  where  MRO  stops  API  unnecessarily. 

1.  Consider  the  creation  of  a  separate  message  when  MRO  is 
used  frequently  for  a  specific  case. 

2.  Determine  if  API  should  be  stopped  when  the  MRO  indicator 
is  established,  but  there  are  no  entries  in  either  the  R5  or  R7  Remarks 
fields. 


3.  Use  a  more  appropriate  message  when  the  situation  calls  for 
it. 


III.  CONCLUSIONS 

A.  New  Message.  The  most  obvious  situation  where  the  MRO  message 
stops  API  frequently  for  a  specific  case  is  when  it  is  automatically 
established  (along  with  the  AHCR  indicator)  upon  receipt  of  MILSCAP 
contracts  and  modifications.  Since  the  indicator  is  established 
automatically,  there  are  no  R5  and  R7  remarks  to  support  the  "9”  in 
this  situation.  We  asked  the  payment  clerks  why  there  were  such  a 
large  number  of  MRO  indicators  in  our  data  base  review  without  R5  and 
R7  remarks.  The  consensus  was  that  they  are  mostly  due  to  the  failure 
to  remove  the  "9"  in  the  RVU-CONTRS  block  after  the  hard  copy  of  a 
MILSCAP  transaction  has  been  reviewed.  The  review  of  MAAPRs  in  our 
sample  shows  payment  personnel  are  removing  the  AHCR  indicator  in  a 
timely  manner.  However,  after  the  AHCR  indicator  is  removed,  personnel 
changing  the  data  base  after  reviewing  the  hard  copy  document  no  longer 
have  evidence  as  to  why  the  MRO  exists.  Therefore,  they  are  reluctant 
to  remove  the  MRO  indicator. 

Establishing  a  new  message  (possibly  HARD  COPY  REVIEW  REQUIRED)  would 
clarify  why  API  is  stopped.  The  Defense  Logistics  Agency  Systems 
Automation  Center  (DSAC)  says  another,  unique  code  could  be  added  to 
the  table  allowed  for  the  RVU-CONTRS  data  field.  To  automatically 
generate  this  code  when  the  hard  copy  is  received  is  considered  to  be  a 
minor  change  requiring  about  one  month  of  programming  effort  (costing 
about  $2,500).  Under  this  suggestion,  MOCAS  would  not  generate  a  "9" 
in  the  RVU-CONTRS  field  when  establishing  the  AHCR  indicator.  To 
ensure  this  new  code  (HARD  COPY  REVIEW  REQUIRED)  is  removed  in  a  timely 
manner,  another  minor  programming  change  is  suggested.  MOCAS  would 
prompt  the  person  inputting  changes  (if  the  HARD  COPY  REVIEW  REQUIRED 
code  exists  on  the  contract)  to  respond  to  an  on  screen  question  such 
as  "Is  your  review  of  the  document  complete?"  When  the  answer  is 
"Yes,"  MOCAS  would  remove  the  indicator  established  for  HARD  COPY 
REVIEW  REQUIRED,  and  API  would  continue  on  the  contract.  This  minor 
program  change  would  involve  another  month  of  effort  on  DSAC's  part, 
costing  another  $2,500. 

The  above  changes  will  assure  the  code  causing  API  stoppage  wil’  be 
removed  in  nearly  all  cases.  The  annual  number  of  manual  MAAr <s  caused 
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only  by  MROs  is  estimated  from  our  sample  to  be  over  46,000  MAAPRs  (5.8 
percent  of  the  estimated  799,253  manual  MAAPRs  in  FY  1990).  The  cost 
of  the  entire  programming  change  is  so  small  ($5,000),  that  eliminating 
only  250  manual  MAAPRs  (eight  tenths  of  a  percent  of  our  annual 
estimate)  makes  the  change  cost  effective.  This  calculation  uses  the 
figure  of  $19.98  per  manual  payment  from  Appendix  C. 

Our  review  of  the  contract  data  base  found,  in  55  percent  of  the 
contracts  reviewed,  there  was  no  indication  in  the  R5  and  R7  remarks 
why  MRO  was  stopping  API.  This  55  percent  is  a  snapshot  in  time  of  the 
contract  data  base  of  one  former  Region,  not  of  the  2  week  sample  of 
manual  MAAPRs  collected  from  each  payment  center.  Nevertheless,  it  is 
a  logical  assumption  to  believe  that  this  frequency  would  be  similar  in 
the  MAAPRs  generated  from  these  contracts  in  the  future.  If  only  30 
percent  of  the  MAAPRs  in  our  2  week  sample  where  MRO  was  the  only 
message  stopping  API  (a  conservatively  low  estimate,  considering  the  55 
percent  figure  above)  were  eliminated  by  this  proposed  M0CAS  change, 
DCMC  would  save  over  $275,000  a  year.  First  year  savings  would  be 
decreased  by  the  fixed  cost  of  the  program  change  ($5,000)  for  a  net 
savings  of  over  $270,000. 

B.  Require  Reason.  The  reason  MRO  is  stopping  API  should  be  noted 
in  the  R5  or  R7  Remarks  field.  Without  the  reason,  the  message  really 
has  little  value.  The  payment  clerk  does  not  know  what  to  do  because 
of  the  MRO  (without  an  explanatory  remark),  or  when  to  remove  It. 

Our  analysis  of  the  contract  data  base  showed  41  percent  of  all  these 
contracts  had  m  entries  in  either  the  R5  or  R7  Remarks  field.  Another 
38  percent  of  these  contracts  had  remarks  In  the  R5  or  R7  fields  that 
either  were  not  reasons  to  stop  API  (17  percent)  -  see  paragraph  II  C, 
or  Indicated  more  appropriate  messages  (21  percent)  -  see  paragraph 
II  C. 

Although  it  Is  generally  agreed  that  MRO  without  valid  R5  and  R7 
remarks  (indicating  the  reason  MRO  is  stopping  API)  should  be 
eliminated,  no  further  programming  effort  should  be  necessary.  Our 
analysis  indicates  the  program  change  In  paragraph  III  A  above,  along 
with  Increased  emphasis  to  use  MRO  only  when  no  other  message  is 
appropriate,  will  eliminate  excessive  MROs.  However,  so  the  contracts 
now  In  the  system  do  not  cause  excessive  MROs  before  the  recommended 
changes  become  effective,  a  purge  program  is  suggested.  This  program 
would  eliminate  the  "9"  from  the  RVU-CONTRS  field  from  all  contracts 
with  no  AHCR  Indicator  and  no  entries  In  either  the  R5  or  R7  blocks. 
This  type  of  program  has  been  run  from  time  to  time  at  the  payment 
centers  and  the  cost  Is  negligible. 

C.  Use  Most  Appropriate  Message.  Of  the  contract  data  base 
entries  we  reviewed,  21  percent  had  R5  or  R7  remarks  indicating  another 
manual  MAAPR  message  would  have  been  more  appropriate. 

At  least  in  the  one  payment  center  where  we  reviewed  the  contract  data 
base,  MRO  is  sometimes  used  to  stop  API  for  the  patent  royalty  and 


withholding  clauses,  and  routinely  used  for  decrease/increase 
modifications  (See  Appendix  G  for  details).  It  may  appear  to  be  a  moot 
point  because  the  Invoice  will  be  paid  manually  whether  It  Is  stopped 
as  an  MRO  or  as  one  of  the  other  appropriate  messages.  However,  once 
the  situation  is  resolved  and  API  could  resume,  It  Is  likely  the  "9" 
will  not  be  removed  and  MRO  will  continue  to  stop  API.  This  would  not 
happen  If  the  appropriate  message  was  used,  then  removed  properly. 

Using  the  proper  message  also  helps  the  payment  clerk  process  the 
manual  payment  faster  and  more  accurately. 

This  change  would  be  easy  to  Implement  (because  It  does  not  Involve 
programming  changes),  but  difficult  to  actually  accomplish  (because  It 
involves  changing  mindsets).  The  savings  for  this  change  in  procedure 
would  be  masked  by  those  calculated  in  paragraph  III  A  above.  However, 
it  would  be  expected  that  the  overall  percentage  of  manual  MAAPRs 
eliminated,  used  in  that  estimate,  would  Increase  to  greater  than  the 
30  percent  used  in  the  calculation. 


IV.  RECOMMENDATIONS 

A.  Add  New  Manual  MAAPR  Message.  Require  a  new  message  for  the 
case  where  MRO  is  automatically  generated  for  MILSCAP  contracts  and 
modifications  (at  the  same  time  the  AHCR  message  is  established).  The 
required  MOCAS  program  change  would  establish  a  new  code  to  designate 
that  the  hard  copy  has  not  yet  been  reviewed.  The  "9"  would  no  longer 
be  used  In  this  situation.  A  manual  MAAPR  message,  such  as  HARD  COPY 
REVIEW  REQUIRED,  would  stop  API  until  the  new  code  is  removed.  As  long 
as  this  new  code  remains  in  the  RVU-CONTRS  field,  an  on-screen  prompt 
will  ask  data  input  personnel  accessing  the  contract  if  the  review  of 
the  MILSCAP  document  (contract  or  modification)  is  complete.  When  this 
response  is  "Yes,"  MOCAS  will  remove  the  code  generating  the  HARD  COPY 
REVIEW  REQUIRED  message,  and  API  will  continue  (if  all  other  conditions 
for  API  are  met).  A  conservative  estimate  of  the  savings  from  this 
change  is  over  $270,000  the  first  year  and  over  $275,000  each 
succeeding  year.  This  estimate  includes  those  generated  by  the 
following  two  recommendations,  as  they  enhance  the  effectiveness  of 
this  MOCAS  change. 

B.  Purge  Contract  Data.  Run  a  purge  program  to  eliminate  the  "9" 
from  the  RVU-CONTRS  field  from  all  contracts  no  longer  having  an  AHCR 
indicator  and  no  entries  In  either  the  R5  or  R7  blocks.  This  will 
prevent  contracts  currently  in  the  system  from  causing  excessive  MROs 
while  the  recommended  changes  take  effect. 

C.  Use  MRO  Message  Judiciously.  Use  MRO  strictly  as  the  catchall 
it  was  designed  to  be.  Clarify  current  procedure  to  restrict  use  of 
this  message  to  only  when  another  message  is  not  appropriate.  See 
Appendix  G  for  details  on  the  use  of  MRO  for  lump  sum  deduction 
modifications. 
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I.  BACKGROUND 

Two  Material  Acceptance  and  Accounts  Payable  Report  (MAAPR)  messages, 

VO  DEDUCTION  PENDING  and  CONTRACTOR  INDEBTEDNESS,  are  used  to 
accomplish  the  same  purpose:  collect  funds  that  contractors  owe  the 
government.  They  are  both  formal  methods  used  to  collect  these  funds; 
the  difference  is  the  level  at  which  the  funds  are  collected.  VO 
DEDUCTION  PENDING  stops  the  Automatic  Payment  of  Invoices  (API)  system 
from  paying  automatically  until  the  funds  are  collected,  for  Invoices 
against  the  contract  for  which  the  funds  are  owed.  When  CONTRACTOR 
INDEBTEDNESS  is  used  to  collect  funds  from  a  contractor,  it  stops  API 
on  all  contracts  for  the  contractor,  until  the  funds  are  collected. 
CONTRACTOR  INDEBTEDNESS  Is  used  when  there  are  Indications  the  funds 
cannot  be  collected  against  the  contract  for  which  the  funds  are  owed. 
It  should  be  used  cautiously  for  large  contractors,  because  It  would 
then  cause  manual  payments  for  all  invoices  submitted  by  the 
contractor. 

Although  the  subject  messages  are  intended  to  collect  funds  already 
paid  to  the  contractor,  they  are  also  appropriately  used  to  stop  API  to 
process  lump  sum  decrease  modifications.  Lump  sum  deduction 
modifications  decrease  the  total  to  be  paid  to  the  contractor. 

However,  they  are  not  usually  funds  already  paid  out  to  the  contractor. 
Since  the  lump  sum  does  not  change  the  unit  price  of  items  on  the 
contract,  there  is  no  way  currently  to  deduct  these  funds  without 
stopping  API  and  manually  making  the  payment. 

As  shown  in  Appendix  F,  the  MANDATORY  REVIEW/OTHER  (MRO)  message  is 
often  used  when  the  VO  DEDUCTION  PENDING  message  (or  CONTRACTOR 
INDEBTEDNESS  if  conditions  warrant)  would  be  more  appropriate.  These 
MAAPRs  are  included  in  this  analysis  of  the  VO  DEDUCTION  PENDING  and 
CONTRACTOR  INDEBTEDNESS  messages,  to  see  If  the  use  of  MRO  in  their 
place  indicates  problems  with  the  subject  messages. 

To  restore  API  when  the  VO  DEDUCTION  PENDING  message  is  applicable,  the 
Credit  Memo  must  be  recoded  to  "F".  When  the  CONTRACTOR  INDEBTEDNESS 
message  is  used,  API  can  on! v  be  resumed  when  the  Office  of 
Telecommunications  and  Information  Services  (OTIS)  manually  removes  the 
indicator  from  the  data  base. 


II.  ANALYSIS 

A.  Frequency  of  the  Messages 

1.  In  the  sample  of  MAAPR  messages  causing  manual  payments 
(see  Appendix  B),  VO  DEDUCTION  PENDING  was  the  eighth  most  frequent 
message,  appearing  3.9  percent  of  the  time.  Half  of  the  times  this 
message  is  on  a  MAAPR  it  is  the  only  message  stopping  API  (almost  2 
percent  of  the  total  number  of  MAAPRs  in  our  sample). 
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2.  CONTRACTOR  INDEBTEDNESS  occurred  rather  infrequently  in  the 
sample,  twentieth  among  all  the  messages  (1  percent  of  the  time).  This 
message  occurs  by  itself,  as  the  only  message  stopping  API,  over  60 
percent  of  the  time  it  is  on  a  MAAPR  (0.7  percent  of  all  the  MAAPRs  in 
the  sample).  Alone  it  is  rather  insignificant,  but  it  becomes 
significant  because  it  is  another  way  to  do  VO  DEDUCTION  PENDING,  thus 
its  frequency  can  be  added  to  the  frequency  of  the  VO  DEDUCTION  PENDING 
message. 


B.  Occurrence  with  Other  Messages.  The  MAAPR- INV  $  NOT  EQUAL 
message  occurs  often  with  both  VO  DEDUCTION  PENDING  and  CONTRACTOR 
INDEBTEDNESS  messages.  However,  payment  personnel  interviewed  could 
not  point  to  specific  reasons  why  this  might  happen.  Since  MAAPR-INV  $ 
NOT  EQUAL  is  the  most  frequent  of  all  the  MAAPR  messages,  it  makes 
sense  that  it  occurs  often  with  these  two  messages. 

C.  Using  MRO  for  Lump  Sum  Deductions.  MRO  was  found  in  Appendix  F 
to  be  used  often  for  processing  lump  sum  deduction  modifications. 
Twenty-one  percent  of  the  contracts  reviewed  (with  the  hard  copy 
already  received  and  MRO  indicator  present)  contained  R5  or  R7  remarks 
indicating  messages  other  than  MRO  were  more  appropriate.  Of  this  21 
percent,  85  percent  (or  18  percent  of  all  contracts  reviewed)  had  R5  or 
R7  remarks  indicating  they  were  for  lump  sum  deduction  modifications. 


III.  FINDINGS 

A.  Appropriateness  of  Messages.  Payment  personnel  indicated  that, 
although  VO  DEDUCTION  PENDING  and  CONTRACTOR  INDEBTEDNESS  are  the  most 
appropriate  for  lump  sum  deduction  modifications,  they  are  too  formal. 
They  rely  on  someone  other  then  the  payment  clerk  to  remove  the 
indicator  stopping  API  after  the  appropriate  funds  have  been  collected. 
The  advantages  to  using  MRO  for  lump  sum  deduction  modifications  are: 
removal  of  the  Indicator  stopping  API  is  under  the  control  of  the 
payment  clerk  and  it  is  possible  to  put  more  information  in  the  R5  and 
R7  remarks  to  allow  a  payment  clerk  to  process  lump  sum  deductions  more 
effectively. 

B.  Analysis.  Three  areas  were  Identified  that  could  yield  savings 
In  the  use  of  the  VO  DEDUCTION  PENDING  and  CONTRACTOR  INDEBTEDNESS 
messages.  One,  Identify  specific  cases  for  which  new  messages  would  be 
more  appropriate.  Two,  evaluate  whether  VO  DEDUCTION  PENDING, 
CONTRACTOR  INDEBTEDNESS  and/or  any  new  messages  could  be  automated, 
thus  avoiding  manual  payments  for  these  situations  altogether.  Three, 
eliminate  the  Instances  where  these,  and  any  other  messages  used  for 
situations  covered  by  these  messages,  continue  to  unnecessarily  stop 
API  after  the  appropriate  funds  have  been  collected. 

1.  The  large  number  of  lump  sum  deductions  processed  under  the 
MRO  message  Indicates  the  need  for  a  new  message  to  process  lump  sum 
deduction  modifications.  The  two  current  messages  are  too  formal  to  be 
used  easily  and  seem  to  encourage  circumventing  prescribed  procedures. 
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a.  Alternatives.  There  are  several  options  to  resolve  the 
problems  encountered  for  this  situation: 

-  A  new  message  for  lump  sum  deductions  only  could  be 
established.  This  would  have  the  advantage,  similar  to  the  advantage 
described  for  the  MRO  message,  of  making  it  clear  to  payment  personnel 
whv  API  is  stopped  for  this  Invoice.  A  disadvantage  Is  there  would  be 
no  automation  of  the  removal  of  the  Indicator  stopping  API. 

-  Automating  the  lump  sum  deduction  process  within  the 
Mechanization  of  Contract  Administration  Services  (MOCAS)  system  would 
negate  the  disadvantage  of  the  previous  option.  The  data  base  would 
include  a  field  where  Input  personnel  could  designate  that  there  is  a 
lump  sum  deduction  and  indicate  the  amount.  The  disadvantage  here  is 
that  there  are  many  different  ways  lump  sum  deductions  can  be  taken, 
limited  only  by  the  imagination  of  the  contracting  parties  Involved. 

The  amount  can  be  taken  on  the  next  Invoice,  on  the  last  invoice, 
incrementally  on  the  remaining  invoices  until  the  total  is  reached, 
incrementally  on  the  next  X  number  of  invoices,  etc.  The  programming 
effort  would  be  monumental. 

-  To  make  automating  a  more  viable  option,  MOCAS  could 
be  changed  to  do  lump  sum  deductions  automatically  for  the  most  common 
situations.  Then,  use  a  new  message  to  stop  API  for  unique  situations. 

b.  Computation  of  savings. 

-  Savings  will  be  estimated  for  the  compromise  option 
described  above,  automating  the  common  types  of  lump  sum  deductions  and 
using  a  new  message  strictly  for  lump  sum  deductions.  The  MAAPRs  that 
would  be  avoided  are  those  with  MRO  messages  where  the  R5  or  R7  remarks 
indicate  API  is  stopped  for  a  lump  sum  deduction.  A  review  of  the  R5 
and  R7  remarks  for  these  MROs  shows  they  are  nearly  all  for  the  common 
types  of  lump  sums  that  should  be  automated. 

-  Eighteen  percent  of  the  contracts  reviewed  in  the 
sample  of  a  former  Defense  Contract  Management  Region  (DCMR)  data  base 
(with  the  hard  copy  already  received  and  MRO  indicator  present) 
contained  R5  or  R7  remarks  indicating  lump  sum  deductions.  See 
paragraph  II  C  above.  Although  this  does  not  translate  directly  to  the 
number  of  MAAPRs  with  MRO  that  are  actually  for  lump  sum  deductions,  it 
is  a  reasonable  assumption  they  will  be  similar.  Rounding  to  the 
conservative  side,  a  figure  of  15  percent  was  used  in  our  estimates. 
This  is  15  percent  of  the  manual  MAAPRs  caused  only  by  MRO  (5.8  percent 
of  all  manual  MAAPRs)  or  almost  7,000  manual  MAAPRs  per  year.  Using 
the  $19.98  per  manual  MAAPR  figure  calculated  in  Appendix  C,  the 
estimated  annual  savings  is  $138,000. 

2.  Automating  the  collection  of  funds  from  contractors  (the  VO 
DEDUCTION  PENDING  and  CONTRACTOR  INDEBTEDNESS  manual  MAAPR  messages)  is 
already  being  planned  as  part  of  Contract  Payment  and  Reporting  (CPR). 
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However,  there  is  a  great  deal  of  savings  to  be  achieved  between  now 
and  the  time  CPR  becomes  operational.  When  either  VO  DEDUCTION  PENDING 
or  CONTRACTOR  INDEBTEDNESS  is  on  a  MAAPR,  over  half  the  time  it  is  the 
only  message  stopping  API.  This  is  2.6  percent  of  all  the  manual 
MAAPRs  in  our  sample,  or  an  estimated  20,000  manual  MAAPRs.  Therefore, 
the  Defense  Logistics  Agency  (DLA)  could  save  an  estimated  $415,000 
annually  by  automating  these  messages. 

3.  Over  half  of  the  MAAPRs  with  either  the  VO  DEDUCTION 
PENDING  or  CONTRACTOR  INDEBTEDNESS  message  were  for  repetitive 
contracts/contractors.  Repetitive  contracts/contractors  were 
conservatively  described  as:  more  than  ten  invoices  against  the  same 
contract  (for  the  VO  DEDUCTION  PENDING  message)  or  more  than  ten 
invoices  against  the  same  contractor  (for  the  CONTRACTOR  INDEBTEDNESS 
message).  The  assumption  was  that  generally  a  debt  would  normally  be 
collected  wi-Mn  ten  invoices.  In  over  half  of  these  cases  (or  1.4 
percent  of  all  the  manual  MAAPRs  in  our  sample),  it  is  the  only  message 
stopping  API.  If  only  half  of  the  repetitive  situations  described 
above  could  be  avoided,  there  would  be  an  estimated  annual  savings  of 
over  $110,000  (nearly  5,600  manual  MAAPRs  could  be  avoided). 


IV.  CONCLUSIONS 

A.  Lump  Sum  Deduction  Modifications.  The  two  messages  studied  do 
not  work  very  effectively  in  the  lump  sum  deduction  modification 
situation.  MOCAS  should  be  changed  to  automatically  process  lump  sum 
deduction  modifications  in  the  most  common  situations.  Whether  it  is 
called  CPR  or  not,  MOCAS  should  be  able  to  automatically  deduct  a  lump 
sum  on,  for  example:  the  next  invoice  submitted  after  the  modification 
is  entered  in  MOCAS,  the  last  invoice  on  the  contract,  and 
incrementally  on  each  succeeding  invoice  until  the  lump  sum  is 
satisfied.  For  the  remaining  situations,  MOCAS  should  continue  to  stop 
API,  but  a  new  message  specifically  for  lump  sum  deductions  should  be 
created.  Automating  lump  sum  deductions  can  save  an  estimated  $138,000 
annually. 

B.  VO  DEDUCTION  PENDING  and  CONTRACTOR  INDEBTEDNESS.  These  two 
messages  serve  their  purpose  and  should  be  retained  as  they  now  stand. 
However,  collecting  these  funds  automatically,  not  making  payments 
manually,  would  save  an  estimated  $415,000  per  year.  Since  these 
functions  are  scheduled  to  be  automated  in  CPR,  the  question  is  not  if, 
but  when  does  it  become  cost  effective  to  implement  this  change. 
Automating  these  functions  avoids  the  necessity  of  eliminating 
repetitive  contracts/contractors  described  above. 

C.  CPR  Considerations.  Automating  lump  sum  deductions,  VO 
DEDUCTION  PENDING  and  CONTRACTOR  INDEBTEDNESS  are  features  of  CPR. 
Savings  from  this  automation  alone  is  estimated  at  $550,000  due  to 
avoiding  27,000  manual  payments.  The  decision  is  not  whether  it  is  a 
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good  idea  to  automate  these  functions,  but  whether  DLA  can  afford  to 
wait  until  CPR  is  implemented.  This  decision  depends  largely  on  when 
CPR  will  be  functional,  which  requires  a  firm  estimated  date  for 
implementing  CPR. 


V.  RECOMMENDATION 

Implement  automated  lump  sum  deductions  and  collection  of  funds 
from  contractors  (VO  DEDUCTION  PENDING  and  CONTRACTOR  INDEBTEDNESS)  at 
the  earliest  possible  time.  This  would  also  include  a  new  MAAPR 
message  to  stop  API  for  the  uncommon  lump  sum  deduction  processing 
option.  Not  automating  these  functions  is  costing  DLA  $550,000  a  year 
to  make  these  payments  manually.  Unless  this  enhancement  is  available 
and  implemented  through  CPR  very  shortly,  use  the  estimated  savings  to 
justify  doing  a  separate  systems  change  now. 
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I. 


INTRODUCTION 


First  Article  (FA)  testing  Is  required  for  specific  Instances  where 
there  may  be  a  problem  with  the  contractor  producing  the  Item.  When  an 
Invoice  Is  received,  the  Mechanization  of  Contract  Administration 
Services  (MOCAS)  system  determines  If  all  line  Items  of  the  contract 
with  FA  requirements  have  been  accepted.  If  any  FA  requirements  are 
not  satisfied,  MOCAS  stops  the  Automatic  Payment  of  Invoices  (API)  and 
generates  a  manual  Material  Acceptance  and  Accounts  Payable  Report 
(MAAPR)  with  the  message  FIRST  ARTICLE  APPROVAL  REQUIRED.  This  stops 
the  government  from  paying  for  production  units  before  the  FA  is 
approved. 

When  payment  center  personnel  process  a  manual  MAAPR  with  this  message, 
they  must  determine  if  the  FA  has  been  approved.  This  is  accomplished 
by  obtaining  a  copy  of  either  the  Procuring  Contracting  Officer's  (PCO) 
letter  to  the  contractor  approving  the  FA,  or  a  copy  of  the  DD  Form 
250,  Material  Inspection  and  Receiving  Report,  signed  in  the  Acceptance 
block  (Source  or  Destination,  depending  on  the  contract  terms). 
Acceptance  for  a  line  item  with  FA  requirements  is  input  using  regular 
DD  250  procedures.  When  all  line  items  with  FA  requirements  have  been 
accepted,  MOCAS  automatically  updates  the  FA  indicator  from  an  "F"  to 
an  "A."  API  then  resumes  if  no  other  conditions  preventing  automatic 
payments  are  present.  If  the  invoice  being  processed  is  the  one  that 
changes  the  "F"  to  an  "A,"  it  will  pay  API. 


II.  ANALYSIS 

A.  Data  Analysis.  Of  those  MAAPR  messages  which  caused  manual 
payments  (see  Appendix  B  for  details),  FIRST  ARTICLE  APPROVAL  REQUIRED 
was  on  almost  4  percent  of  the  manual  pays.  This  was  the  ninth  most 
frequent  of  the  over  50  messages  in  the  sample.  FIRST  ARTICLE  APPROVAL 
REQUIREO  was  the  only  message  stopping  API  1.6  percent  of  the  time. 

Intuitively,  these  numbers  seem  large  for  the  situation  this  message 
should  represent.  It  means  an  acceptance  document  (usually  a  DD  Form 
250)  generated  a  MAAPR  on  a  contract,  and  MOCAS  shows  one  or  more  line 
items  with  FA  requirements  that  have  not  been  processed  as  accepted. 

If  the  data  base  is  correct,  this  should  happen  only  when  there  is  more 
than  one  line  item  with  FA  requirements  on  a  contract  and  they  have  not 
all  been  accepted  yet.  The  DD  250  that  generates  the  MAAPR  for 
production  items  is  signed  by  the  Quality  Assurance  Representative 
(QAR).  Since  the  QAR  is  not  supposed  to  sign  the  acceptance  document 
until  all  contractual  terms  (including  FA  acceptance)  have  been  met, 
there  should  not  be  manual  MAAPRs  (with  the  FIRST  ARTICLE  APPROVAL 
REQUIRED  message)  generated  for  production  items.  A  manual  MAAPR  for 
production  items  with  this  message  would  mean  that  the  contractor  has 
invoiced  for  production  items  before  all  contractual  FA  requirements 
have  been  met. 
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Many  of  the  700  MAAPRs  in  our  sample  with  the  FIRST  ARTICLE  APPROVAL 
REQUIRED  message  were  for  the  same  contract  and  call  order,  but 
different  shipments.  The  shipment  numbers  on  many  of  these  were  rather 
high  (greater  than  5).  This  would  indicate  these  shipments  were 
probably  for  production  Items,  for  which  MOCAS  is  indicating  the  FA  was 
not  yet  accepted.  This  would  actual  1 v  be  the  case  for  extremely  rare 
situations,  such  as  when  the  PCO  notifies  the  contractor,  in  writing, 
that  they  can  ship  before  the  FA  has  been  approved.  The  number  of 
MAAPRs  where  this  happened  in  the  sample  does  not  indicate  a  rare 
situation  as  described  above,  but  rather  a  data  base  or  procedural 
problem. 

B.  FA  Approval  Process  in  MOCAS.  Three  payment  centers,  the 
Defense  Logistics  Agency  (DLA)  Finance  Center  (DFC),  and  the  DLA 
Systems  Automation  Center  ( DSAC)  provided  information  about  the  way 
MOCAS  stops,  then  restores,  API  for  FA  approval.  The  payment  centers 
all  process  FA  acceptance  the  same  way.  They  delete  data  field 
ACT-FRST-AR  (FIRST  ARTICLE  ACCEPTANCE  DATE),  on  the  line  item  record 
and  the  "F"  from  data  field  SPC-CON-PVN  (SPECIAL  CONTRACT  PROVISIONS) 
on  the  provisions  data  record. 

The  above  procedure  seems  unduly  complicated.  We  asked  DSAC  if  this  is 
the  way  this  process  should  work.  They  said  MOCAS  stops  API  when  data 
field  PRE-PROD-SP  (FIRST  ARTICLE/PREPRODUCTION  SAMPLE)  on  the 
provisions  data  record,  is  an  "F."  This  is  confusing  because  this  data 
element  is  actually  the  FA  Status  Indicator,  although  it  is  hard  to 
tell  from  the  field  name.  This  "F"  is  automatically  generated  upon 
input  of  a  date  in  the  FA  Acceptance  Due  Date  (ACT-FRST-AR)  field  on 
the  line  item  record.  When  acceptances  for  all  line  items  containing 
FA  requirements  have  been  processed  (using  normal  DP  250  processing 
procedures),  the  "F"  in  the  PRE-PROD-SP  field  changes  to  an  "A"  and 
lU sms  -API  to  resume. 

That  MOCAS  is  not  being  used  properly  to  process  FA  Approvals  was 
demonstrated  when  we  looked  at  MOCAS  data  base  for  contracts  with 
FA  requirements  in  one  of  the  former  Defense  Contract  Management 
Regions  (DCMRs).  Of  the  129  contracts  with  FA  requirements,  21  had  an 
"F"  in  the  PRE-PROD-SP  field  when  the  data  showed  it  no  longer  was 
appropriate.  Four  of  these  no  longer  had  a  date  In  the  ACT-FRST-AR 
field,  17  of  these  showed  all  line  items  with  FA  requirements  as 
accepted.  Any  invoice  against  these  contracts  will  be  manual  payments 
(because  of  the  ”FH  in  the  PRE-PROD-SP  field).  These  manual  payments 
would  have  been  avoided  if  FA  requirements  were  processed  properly,  if 
incorrectly  remains  in  the  provisions  data  record  because  the 
ling.  Hen  was  Improperly  processed  for  FA  requirements,  all  subsequent 
payments  will  be  manual.  Two  situations  may  have  led  to  the  "F" 
improperly  remaining  as  the  status: 


-  If  the  payment  center  deletes  the  ACT - FRST -Art  field 
before  the  system  processes  the  acceptance  for  that  line  Item,  the  "F" 
indicator  may  not  update.  When  the  system  gets  the  acceptance  to 
process,  there  is  no  date  in  the  ACT-FRST-AR  field.  MOCAS  doesn't  know 
it  is  processing  an  FA  requirement. 

-  If  the  date  in  the  ACT-FRST-AR  field  Is  Input  after  the 
acceptance  for  that  line  item  has  been  processed,  the  "F"  indicator 
will  not  change  automatically.  In  this  case,  the  indicator  is 
generated  after  the  acceptance  Is  processed.  Since  the  acceptance 
action  will  never  occur  again,  the  indicator  has  no  chance  to  change 
from  "F"  to  "A."  Therefore,  API  may  never  resume  on  this  contract. 

The  confusion  about  processing  the  FA  acceptance  stems  In  part  from  the 
"F"  in  2  different  fields  (SPC-CON-PVN  and  PRE-PROD-SP)  on  the 
Provisions  Data  screen,  meaning  that  a  First  Article  is  required. 
However,  the  "F"  in  the  SPC-CON-PVN  field  does  not  change  to  an  "A," 
since  an  "A"  indicates  another  contract  provision  (Liquidated  Damages). 

C.  Impact  on  Contract  Management.  Deleting  the  "F"  in  the 
SPC-CON-PVN  field  and  deleting  the  date  In  the  ACT-FRST-AR  field 
adversely  impacts  Contract  Management.  Contracts  fall  out  of  Part  A  of 
the  CAR  if  FA  is  the  only  reason  they  are  there.  They  also  lose 
visibility  over  which  line  items  were  for  FA  tests. 


III.  ALTERNATIVES.  Three  possible  alternatives  were  considered:  the 
way  the  process  is  now  programmed  to  work;  implementing  a  minor  program 
change  to  make  the  process  easier  to  use  and  understand;  and  deleting 
the  requirement  to  stop  API  for  FA  approval.  The  reason  MOCAS  now 
stops  API  for  FA  approval  is  so  the  government  Is  not  put  in  the 
position  of  paying  invoices  when  not  contractually  authorized.  In  this 
case,  we  are  not  contractually  allowed  to  pay  for  production  units  If 
the  FA  has  not  been  accepted.  How  well  this  Is  done  by  the 
alternatives  will  be  assessed. 

A.  Current  MOCAS  Procedure.  Retain  the  process  as  it  is 
programmed  to  work,  allowing  MOCAS  to  update  the  FA  indicator  and 
restore  API  automatically. 

ANALYSIS  -  The  drawback  to  this  is  that  it  is  confusing  as  to  the 
meaning  and/or  purpose  of  the  PRE-PROD-SP  field.  Also,  as  the  current 
situation  illustrates,  people  do  not  process  the  FA  Approval  properly 
because  they  do  not  understand  how  it  works.  If  this  alternative  is 
adopted  and  people  are  instructed  to  "do  it  the  way  the  system  is 
supposed  to  work,"  in  all  likelihood  improper  input  will  continue,  or 
resume  after  some  time  has  passed.  Effectively,  there  is  no  risk  with 
this  alternative  because  we  do  not  pay  until  the  FA  Approval  is  in 
MOCAS.  But  there  is  a  cost.  The  improperly  handled  FAs  are  manual 
payments  due  to  system  ineffectiveness. 


B.  MQCAS  Systems  Change.  Another  alternative  is  a  minor  MOCAb 
program  change. 

1.  Change  the  PRE-PROD-SP  field  on  the  Provisions  Data  screen 
to  something  more  descriptive,  like  FA-STATUS.  The  indicators  for  this 
field  should  be  changed  to  "D"  for  Due  n6  "A"  for  Accepted.  This  will 
avoid  the  confusion  of  using  "F,"  indicating  an  FA  is  due,  for  two  data 
elements  (SPC-CON-P'vN  and  PRE-PROD-SP),  but  for  different  purposes. 
Retain  the  way  this  Indicator  automatically  changes  and  restores  API. 

2.  On  the  line  item  data  record,  making  the  ACT-FRST-AR  field 
something  clearer,  like  FA-ACP-DUE,  would  improve  the  accuracy  of  the 
data  in  this  field.  This  is  one  of  the  most  important  fields  in  the  FA 
acceptance  process,  since  a  date  entered  here  triggers  the  "F"  in  both 
the  SPC-CON-PVN  and  PRE-PROD-SP  (FA-STATUS)  fields. 

ANALYSIS  -  This  is  a  viable  alternative.  The  programming  effort 
Involves  changing  data  field  names  and  one  indicator  value.  DSAC 
estimates  this  change  would  take  about  6  months  and  would  cost 
approximately  $15,000.  Because  they  would  consider  it  a  clarification 
change,  DSAC  feels  it  would  get  a  low  priority.  The  risk  of  paying  for 
production  items  before  FA  approval  is  no  greater  than  we  currently 
assume.  Of  the  MAAPRs  where  this  Is  the  only  message  stopping  API  (1.6 
percent  of  the  total  number  of  manual  MAAPRs),  almost  two  thirds  of 
these  are  invoices  on  contracts  where  at  least  five  other  shipments 
have  been  made.  It  seems  reasonable  that  when  you've  made  at  least 
five  shipments,  the  FA  has  really  been  accepted  and  the  data  base  is 
more  than  likely  wrong.  Estimating  from  our  sample,  we  could  avoid 
8,500  manual  payments  a  year,  with  potential  yearly  savings  of  over 
$170,000.  The  savings  figure  uses  $19.98  as  the  cost  of  an  average 
manual  payment  (see  Appendix  C).  The  net  savings  for  this  MOCAS  change 
Is  over  $165,000  the  first  year  and  over  $170,000  for  each  succeeding 
year. 

C.  Stop  Manual  Payments  for  FA  Requirements.  The  change  here  is 
to  continue  API  even  when  the  data  base  Indicates  FA  Approval  is  still 
required  Invoice  and  Acceptance  documents  would  be  processed  as  they 
are  now. 

ANALYSIS  -  This  alternative  would  eliminate  all  manual  payments  where 
the  only  message  stopping  API  Is  FIRST  ARTICLE  APPROVAL  REQUIRED 
(almost  1.6  percent  of  all  manual  MAAPRs  based,  on  our  sample).  The 
estimated  annual  savings  from  this  alternative  are  over  $250,000 
(almost  13,000  manual  payments  would  be  avoided).  DSAC  personnel  say 
programming  effort  would  be  minimal,  as  this  would  simply  be  a  matter 
of  removing  this  message  from  the  table  of  messages  that  stop  API. 
Therefore,  the  net  savings  for  this  option  are  over  $250,000  a  year. 

The  primary  concern  with  this  option  Is  the  amount  of  risk  the 
government  will  assume.  That  Is,  that  a  contractor  might  be  paid 
without  meeting  FA  Requirements.  The  degree  of  risk  with  this 
alternative,  In  reality,  Is  not  much  greater  than  currently  exists. 
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The  primary  protection  against  this  risk  Is  that  no  Invoice  Is  paid 
without  an  acceptance  document,  signed  either  at  Source  or  Destination. 
The  DCMR  Chicago  Office  of  Counsel  stated  this  signature  means  that  the 
government  representative  is  saying  that  all  terms  of  the  contract  have 
been  met.  In  the  context  of  this  appendix,  this  means  that  they  only 
sign  the  acceptance  document  when  they  know  the  FA  has  been  approved. 

The  reason  the  government  representative  signing  the  acceptance 
document  knows  the  FA  Is  approved,  and  the  payment  office  doesn't,  lies 
in  the  way  buying  activities  transmit  FA  Approval  to  Interested 
parties.  Defense  Federal  Acquisition  Regulation  Supplement  (DFARS) 
Appendix  I  contains  the  Instructions  for  using  the  DD  Form  250.  In 
cases  where  the  acceptance  Is  at  Destination  (as  are  most  FA  tests), 
the  acceptance  is  not  required  to  be  sent  to  the  contractor.  To  remedy 
this  lack  of  notification  to  the  contractor,  the  FA  Test  clause  In  the 
FAR  states  the  Contracting  Officer  (CO)  will  notify  the  contractor  in 
writing  of  the  approval,  conditional  approval,  or  disapproval  of  the 
FA.  This  creates  two  sets  of  documents  the  CO  transmits,  to  different 
parties,  to  notify  them  of  the  disposition  of  the  FA.  What  typically 
happens  is  the  CO  sends  the  written  disposition  to  the  contractor 
without  forwarding  the  signed  acceptance  to  the  paying  office.  The 
paying  office  then  has  to  search  for  the  letter  of  approval  to  the 
contractor,  since  this  is  usually  the  only  document  available.  Since 
this  letter  is  proof  there  has  been  acceptance  of  the  FA,  it  is 
considered  to  be  a  proper  acceptance  document. 

Since  contracts  stipulate  what,  If  any,  part  of  production  can  begin 
before  FA  is  approved  (for  example,  the  purchase  of  long  lead  time 
items),  the  contractor  is  not  really  even  allowed  to  submit  production 
items  unless  the  FA  is  approved.  If  we  paid  a  contractor  for 
production  items  and  the  FA  was  really  not  approved,  there  is  little 
chance  that  the  situation  was  ngi  due  to  fraud  or  willful  misconduct. 
Because  there  is  very  little  risk,  in  reality,  this  alternative  is  a 
very  viable  option. 


IV.  CONCLUSION.  Although  all  the  alternatives  discussed  above  are 
viable,  the  last  one  discussed,  discontinue  stopping  API  for  FA 
requirements,  offers  the  most  payback.  Annual  savings  of  over  $250,000 
for  this  alternative  can  be  achieved  through  the  elimination  of  almost 
13,000  manual  payments  a  year.  After  discussions  with  the  DCMR  Chicago 
Office  of  Counsel,  we  concluded  that  the  risk  the  contractor  will  ship 
production  items  without  FA  Approval  is  commensurate  with  the  other 
alternatives  studied.  This  is  based  on  the  fact  that  payment  cannot  be 
made  without  an  acceptance  document  signed  by  a  government  QAR.  When 
the  government  QAR  signs  the  acceptance  document,  he/she  is  stating  all 
contract  conditions  (including  FA  Approvals)  have  been  satisfied.  Even 
the  action  of  the  contractor  offering  production  items  without  the 
required  FA  approval  would  be  a  violation  of  contract  terms.  The 
government  will  still  be  susceptible  to  fraud  or  willful  misconduct, 
but  that  risk  also  exists  now. 
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V.  RECOMMENDATION.  Implement  the  following  MOCAS  change  and  the 
corresponding  procedure:  delete  FIRST  ARTICLE  APPROVAL  REQUIRED  from 
the  table  of  those  messages  that  stop  API  and  pay  all  invoices  with  FA 
requirements  automatically.  There  is  already  adequate  protection  in 
place  to  prevent  the  contractor  from  receiving  payment  without  approval 
of  the  FA  test.  This  in  no  way  impacts  FA  Requirements  in  a  contract, 
it  only  recommends  that  DLA  pay  all  invoices  on  these  contracts  using 
API. 
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I.  INTRODUCTION 


Several  clauses  may  be  Involved  when  the  Free  On  Board  (FOB)  point  In  a 
contract  is  Origin.  (The  FOB  point  determines  who  assumes  the  risk  of 
transportation  of  the  material.  When  FOB  is  origin,  the  government 
assumes  this  risk). 

Federal  Acquisition  Regulation  (FAR)  clause  52.247-61,  FOB  Origin  - 
Minimum  Size  of  Shipments,  requires  the  contractor  to  ship  in  carload 
or  truckload  lots  except  as  otherwise  directed  in  writing  by  the 
Contracting  officer.  The  contractor  is  liable  for  any  increased  cost 
to  the  Government  if  shipments  made  within  a  delivery  period  were  not 
consolidated.  For  example,  a  company  might  choose  to  make  ten  small 
parcel  post  shipments  during  one  specified  delivery  period.  If  these 
ten  shipments  could  have  been  more  economically  combined  into  one 
truckload  shipment,  the  contractor  could  be  liable  for  the  excess 
shipping  costs.  When  this  clause  is  in  the  contract,  the  Mechanization 
of  Contract  Administration  Services  (MOCAS)  system  stops  the  Automatic 
Payment  of  Invoice  (API)  from  paying  automatically.  On  the  final 
payment,  (only  if  there  have  been  multiple  shipments),  MOCAS  generates 
a  manual  Material  Acceptance  and  Accounts  Payable  Report  (MAAPR)  with 
the  message  FOB  ORIGIN/MINIMUM  SIZE  (FOBOMS). 

The  closely  related  Guaranteed  Maximum  Shipping  Weight  and  Dimensions 
(GMSW)  clause  described  by  FAR  52.247-60  also  deals  with  FOB  Origin 
shipments.  As  part  of  the  contract  offer,  the  contractor  is  requested 
to  state  shipment  weights  and  dimensions.  If  separate  containers  are 
to  be  banded  or  skidded  into  a  single  unit,  specific  weights  and 
dimensions  must  be  provided.  If  delivered  goods  exceed  the  maximum 
weight  and/or  dimensions  agreed  upon,  the  contractor  may  be  liable  for 
the  extra  shipping  costs.  When  this  clause  is  in  the  contract,  MOCAS 
stops  API  on  the  final  payment,  even  if  there  was  only  one  shipment. 

The  message  on  the  manual  MAAPR  in  this  case  is  GUARANTEED  MAXIMUM 
SHIPPING  WEIGHT  (GMSW). 

These  clauses  were  combined  in  one  cost-benefit  analysis  because  many 
of  the  same  criteria  are  used  when  they  are  included  in  contracts. 

When  either  or  both  of  these  clauses  are  in  a  contract,  the 
Mechanization  of  Contract  Administration  Services  (MOCAS)  system 
generates  a  listing  (BGBA  26)  before  the  final  payment  is  made.  This 
Transportation  Officer  Approval  Alert  (TOAA)  listing  informs  the 
transportation  office  that  final  payment  on  this  contract  is  about  to 
be  made  and  indicates  that  one  or  both  of  these  clauses  are  present  in 
the  contract.  The  Transportation  Officer  then  reviews  all  shipments 
made  up  to  this  point  to  ensure  compliance  with  these  clauses. 


II.  ANALYSIS 

One  major  cost  involved  in  this  analysis  is  the  cost  of  manually  paying 
an  invoice  versus  the  cost  of  an  automatic  payment  through  API.  We 
estimated  that  making  a  payment  manually  costs  $19.98  more  than  an 
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automatic  payment.  API  is  stopped  on  the  final  payment  for  these  two 
clauses,  as  described  above,  to  let  the  Transportation  Officer  review 
all  shipments  made  under  this  contract  to  check  for  compliance  with 
these  clauses.  It  also  enables  the  Government  to  recoup  possible 
overcharges  on  the  final  invoice. 

These  clauses  are  occasionally  input  into  MOCAS  when  they  should  not 
be,  but  our  sample  did  not  uncover  widespread  problems.  They  are 
incorrectly  input  at  times  for  FOB  Destination  shipments  or  for  Foreign 
Military  Sales  (FMS).  These  clauses  should  not  be  included  for 
contracts  under  $25,000,  and  the  Defense  Logistics  Agency  (DLA)  should 
be  sure  all  payment  centers  follow  this  established  procedure. 

Another  cost  involved  is  the  cost  of  the  Transportation  Officer 
compliance  review.  These  reviews  are  intended  to  ensure  the  primary 
benefit  of  these  clauses,  which  is  the  use  of  efficient,  low-cost 
shipping  methods.  The  average  time  a  Traffic  Management  Specialist 
needs  to  do  a  review  of  this  type  is  about  one  hour.  The  Specialist 
must  first  locate  the  contract  in  question  along  with  the  necessary 
shipping  documents,  such  as  the  bill  of  lading. 

These  facts  lead  to  the  following  questions:  Is  it  cost  efficient  to 
include  these  clauses  in  contracts?  How  much  economic  benefit  does  the 
Government  derive  from  these  clauses?  Would  it  be  possible  to 
eliminate  or  curtail  the  use  of  these  clauses  to  the  benefit  of  the 
Government? 


III.  RESULTS 

Most  contractor  payments  made  under  the  current  cash  management  program 
suspend  (are  delayed)  for  at  least  25  days.  Some  payments  do  not 
suspend,  such  as  progress  payments,  bureau  vouchers  (BVNs),  and 
payments  under  certain  discount  terms.  The  vast  majority  of  payments 
do  suspend,  however,  and  this  25  day  period  is  more  than  enough  time 
for  the  Transportation  office  to  review  shipments  for  compliance  to 
these  clauses.  In  fact,  in  most  cases  Transportation  sends  a  response 
back  to  the  Payment  office  within  one  week  approving  or  disapproving 
payment.  If  the  contractor  has  overcharged  for  transportation 
expenses,  the  Payment  office  can  adjust  the  amount  of  this  final 
payment . 

Given  this  25  day  delay  for  payments,  there  is  nfi  compelling  reason  to 
stop  an  API  for  these  clauses.  The  TOAA  listing  alerts  the 
Transportation  Officer  well  ahead  of  actual  payment  of  the  final 
invoice.  If  there  was  a  noncompliance  problem,  the  Transportation 
Officer  In  most  cases  could  notify  the  payment  personnel  before  final 
payment.  In  the  unlikely  event  that  the  final  payment  were  released 
and  there  was  an  overpayment,  a  demand  letter  could  be  sent  to  the 
contractor  to  recoup  the  overcharge.  The  Government  is  very  rarely 
overcharged  In  this  manner.  When  an  overcharge  does  occur,  it  is  often 
for  such  a  small  dollar  amount  that  It  is  not  worthwhile  to  try  to 


recover  It.  The  transportation  officers  contacted  regarding  these 
reviews  all  said  incidences  of  overcharge  recoveries  have  been  very 
infrequent.  One  15-year  veteran  said  he  could  remember  only  one 
incidence  of  recovery  of  a  substantial  amount.  To  illustrate  further, 
the  Defense  Contract  Management  District  Northeast  Transportation 
office  (DCMDN-AT)  in  Boston  found  no  evidence  of  savings  for  1,704 
reviews  done  in  a  6-month  period. 

Boilerplating  of  these  clauses  is  not  a  major  problem.  However,  buying 
activities  occasionally  include  them  in  contracts  only  because  they 
were  in  earlier  contracts  involving  the  same  contractor,  even  if  the 
items  and  shipping  terms  are  completely  different.  Also,  the  inclusion 
of  FOBOMS  and  GMSW  is  up  to  the  discretion  of  the  many  individual 
buying  activities.  Even  with  these  disparities,  there  Is  little 
evidence  of  widespread  boilerplating  and  it  does  not  cause  problems  for 
DLA. 


IV.  CONCLUSIONS 

The  FOBOMS  and  GMSW  clauses  protect  Government  interests  by  making 
contractors  aware  of  shipping  requirements  and  responsibilities. 
Therefore,  it  would  not  be  wise  to  stop  using  these  clauses.  However, 
DLA  does  need  to  change  the  way  it  reacts  to  payments  Involving  these 
clauses. 

This  study  found  that  there  were  no  valid  reasons  why  API  payments 
should  be  stopped  when  these  clauses  are  present.  The  vast  majority  of 
contractor  payments  are  delayed  now  anyway  due  to  the  cash  management 
system.  This  delay  allows  enough  time  for  any  reviews  that  might  be 
necessary.  Letting  these  payments  go  API  instead  of  creating  a  manual 
payment  would  save  about  $316,000  each  year.  (See  Attachment  1  for 
computation  of  savings.) 

The  reviews  which  are  done  to  check  for  compliance  with  these  clauses 
have  been  shown  to  yield  almost  no  cost  savings.  The  cost  of  doing 
these  reviews,  which  is  about  $26.71  each,  makes  this  a  very  expensive 
program  for  which  the  benefits  are  extremely  small.  We  project  that 
about  14,000  reviews  per  year  are  done  DLA-wide  and  that  the  Defense 
Contract  Management  Command  (DCMC)  spends  approximately  $374,000  yearly 
to  i'. j  these  reviews  (See  Attachment  2).  Our  current  procedure  of 
stopping  API  and  having  Transportation  review  all  contracts  with  these 
clauses  is  wasteful  and  should  be  changed. 

However,  eliminating  all  reviews  would  not  be  a  viable  option  because 
the  possibility  of  repeated  fraudulent  charges  would  exist.  Even 
though  this  scenario  is  unlikely,  to  protect  Government  interests,  some 
reviews  should  still  be  done.  One  option  would  be  to  have  an  outside 
contractor  do  the  reviews.  Also,  new  criteria  for  doing  reviews  could 
be  determined  by  the  Transportation  office,  such  as  a  dollar  amount 
threshold  for  contracts.  Because  the  level  of  contractor  compliance  is 
high,  using  a  sampling  plan  would  be  a  more  viable  option.  A 
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stratified  sampling  plan  that  concentrates  most  heavily  on  large  dollar 
amount  contracts  would  be  the  best  type  of  sampling  to  use.  A  MOCAS 
programming  change  would  not,  be  necessary  because  the  actual  sampling 
could  be  done  in  the  Transportation  office  using  existing  MOCAS 
listings. 


V.  RECOMMENDATIONS 

A.  Do  Not  Stop  API .  Do  not  stop  automatic  payments  when  either  or 
both  of  these  clauses  are  present.  The  vast  majority  of  payments 
suspend  for  25  days  for  cash  management.  Therefore,  for  most  payments 
there  is  sufficient  time  to  review  a  contract  for  compliance,  if 
necessary,  before  the  final  payment  is  actually  released.  Based  on  the 
two-week  sample  of  MAAPR  messages,  not  stopping  API  for  these  messages 
would  yield  a  yearly  savings  of  $316,000  (See  Attachment  1). 

B.  Use  A  Stratified  Sampling  Plan.  Do  not  review  compliance  of 
every  contract  that  contains  these  clauses.  The  reviews  done  by  the 
Transportation  Office  to  check  for  compliance  have  provided  almost  no 
payback.  Because  compliance  with  these  clauses  is  so  high,  the 
Government  rarely  needs  to  collect  any  overpayment.  The  TOAA  listing 
notifies  the  Traffic  Management  Specialist  before  the  final  payment  is 
made.  This  person  could  use  the  listing  but  review  only  a  sample  of 
the  shipments  on  each  listing. 

Since  contractor  compliance  is  extremely  high,  we  recommend  using  a 
stratified  sampling  plan  to  select  shipments  for  review.  Stratified 
sampling  would  be  much  more  cost  effective  than  our  current  procedures. 
For  example,  reviewing  just  1  out  of  every  15  shipments  would  save 
almost  $350,000  each  year  (See  Attachment  3).  In  order  to  realize  the 
highest  payback  from  reviews,  the  sampling  plan  should  concentrate  on 
reviews  of  shipments  for  large  dollar  amount  contracts.  This  type  of 
sampling  would  not  require  a  MOCAS  system  change  because  Transportation 
would  do  the  actual  sampling  using  listings  MOCAS  already  generates. 
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Attachment  1 

Cost  of  Manual  Payments  Due  to  FOB  ORIGIN/MINIMUM  SIZE  and/or 
GUARANTEED  MAXIMUM  SHIPPING  WT 


Based  on  two-week  sample  of  MAAPR  messages: 

389  MAAPRs  (1.98%  of  all  MAAPRs)  had  FOBOMS  and/or  GMSW  as  the  only 
message(s)  stopping  API. 

1.98%  X  799,253  manual  pays  per  yr.  X  $19.98  (cost  per  manual  pay) 
«  $316, 187/yr. 
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Attachment  2 


Cost  of  Transportation  Specialist  to  Review  for  Compliance 


GS-11  Step  5 

Fringe 

Leave  and 

Hours  per 

Hourly  wage 

benefits 

Training  adj. 

review 

16.90  X 

1.2955  X 

1.22 

X 

1.0 

=  $26. 

71  per  review 

$26.71  X 

14,000  reviews 

per  year  =  $373,940 

per  year 
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Attachment  3 


Annual  Savings  Associated  with  Possible  Sampling  Plans 


Which 

Final  Shipments 
Reviewed 

Number  of 
Reviews 

Cost  of 

Transportation 

Reviews 

Savings  on 

Transp. 

Reviews 

Total 

Savinas(l) 

All  (currently) 

14,000 

$373,940 

... 

$316,187 

1  of  each  10 

1,400 

$37,394 

$336,546 

$652,733 

1  of  each  15 

933 

$24,920 

$349,020 

$665,207 

1  of  each  20 

700 

$18,697 

$355,243 

$671,430 

(1)  -  Total  Savings  figures  include  savings  from  performing  fewer 
transportation  reviews  and  savings  from  paying  API  instead  of  manually. 
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I. 


Introduction 


This  study  examines  ways  that  Electronic  Data  Interchange  (EDI)  could 
be  used  to  avoid  manual  input,  reduce  errors  and  increase  the  Automatic 
Payment  of  Invoice  (API)  rate.  On  11  September  1990,  an  Executive 
Level  Group  (ELG)  for  Defense  Corporate  Information  Management 
submitted  its  "Plan  for  Corporate  Information  Management  for  the 
Department  of  Defense"  to  the  office  of  the  Secretary  of  Defense.  Some 
of  the  issues  addressed  by  the  ELG  apply  directly  to  specific  contract 
payment  operations. 

Errors  are  introduced  into  the  Mechanization  of  Contract  Administration 
Services  (MOCAS)  payment  data  base  at  various  points  in  the  payment 
cycle.  When  a  procurement  instrument  (contract  or  contract 
modification)  is  written,  a  clerk  at  the  buying  activity  will  input  the 
data  into  the  procurement  data  base  (Standard  Automated  Materiel 
Management  Systems  -  SAMMS,  Acquisition  Management  Information  Systems 
-  AMIS,  etc.).  A  hard  copy  of  this  procurement  instrument  is  then  sent 
to  the  administering  activity  where  the  data  is  manually  input  into  the 
MOCAS  data  base.  After  contractors  perform  pursuant  to  contract  they 
mail  an  invoice  for  payment,  typed  by  contractor  personnel,  to  the 
payment  office.  This  invoice  data  is  also  manually  entered  into  MOCAS. 
A  keypunch  error  at  any  point  in  this  cycle  will  result  in  inaccurate 
MOCAS  data.  Inaccurate  unit  costs,  quantities,  Accounting 
Classification  Record  Numbers  (ACRNs),  or  other  data  elements  could 
stop  API.  Given  the  extraordinary  number  of  payments  made  by  the 
Defense  Contract  Management  Command  (DCMC),  and  by  the  Defense  Finance 
and  Accounting  Service  (DFAS)  in  particular,  the  likelihood  for  errors 
is  great. 

Part  of  the  inaccurate  data  base  problem  can  be  addressed  through  the 
use  of  EDI.  For  example,  the  most  prevalent  single  cause  of  manual 
payments  was  the  Material  Acceptance  and  Accounts  Payable  Report 
(MAAPR)  message  of  MAAPR-INV  $  NOT  EQUAL  (MAAPR  and  Invoice  dollar 
amounts  are  not  equal).  This  message  occurs  on  30  percent  of  all 
manual  MAAPRs.  Most  manual  payments  with  this  message  are  due  to 
either  an  input  error  or  a  data  receipt-timing  problem.  The  timing 
problem  happens  when  a  contract  modification  that  alters  the  contract 
price  has  not  yet  been  received  by  the  payment  office.  Use  of  EDI 
could  eliminate  most  data  input  mistakes  and  the  timing  problem. 

Department  of  Defense  (DoD)  contracting  offices  currently  employ  EDI 
technology  through  Military  Standard  Contract  Administration  Procedures 
(MILSCAP).  MILSCAP  is  a  set  of  electronic  documents  designed  to  allow 
buying  activities  and  contract  administration  offices  to  send  data  back 
and  forth  regarding  the  content  and  status  of  contracts.  The  MILSCAP 
contract  abstract  allows  the  buying  activity  to  electronically  transmit 
contract  information  from  their  data  base  into  MOCAS  without  the  need 
for  clerical  intervention. 
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Contract  modifications  provide  an  especially  fertile  field  to  reap 
benefits  from  EDI  technology.  Whenever  a  contract  is  changed  and  an 
invoice  beats  the  hard  copy  modification  to  the  payment  office,  a 
manual  payment  results.  Using  MILSCAP  modifications  to  pay,  instead  of 
waiting  for  hard  copies,  could  greatly  reduce  the  number  of  manual 
payments  due  to  the  speed  of  EDI.  MILSCAP  was  designed  to  allow  the 
electronic  transmission  of  structured  and  discrete  data;  therefore  in 
theory  the  quality  of  MILSCAP  data  should  not  pose  a  hindrance. 

EDI  also  lends  itself  well  to  the  area  of  invoicing.  Currently  when 
invoices  are  received  they  are  sorted  by  hand  to  the  proper  payment 
center  input  cell  where  they  are  typed  into  MOCAS.  Two  Defense 
Contract  Management  Districts  -  DCMDM  (Mid  Atlantic)  and  DCMDN 
(Northeast),  along  with  the  Defense  Systems  Automation  Center  (DSAC), 
have  efforts  under  way  to  allow  contractors  the  option  of  submitting 
invoices  electronically  which  can  then  be  loaded  directly  into  MOCAS. 


II.  METHODOLOGY 

Separate  analyses  were  done  for  contract  and  invoice  data  input,  the 
two  payment  areas  that  involve  most  of  the  data  input  in  the  payment 
centers.  The  evaluations  look  at  using  MILSCAP  for  input  of  contract 
and  modification  abstracts,  and  using  EDI  for  invoicing.  The  analysis 
is  based  on  interviewing  personnel  involved  with  contract  payment,  and 
other  research  of  payment  procedures  and  MILSCAP  documentation. 

A.  MILSCAP  Contract  Data.  Approach: 

1.  Analyze  whether  MILSCAP  has  the  data  that  is  required  to 
pay  or  can  be  updated  to  include  such  data. 

2.  Evaluate  the  effort  required  and  the  practicality  of 
updating  MILSCAP. 

3.  Assess  the  costs  and  benefits  of  updating  MILSCAP. 

B.  Electronic  Invoices.  Approach: 

1.  Identify  practical  methods  of  achieving  electronic  invoice 
transmission.  Review  the  status  of  current  DLA/DoD  initiatives  in  this 
area. 


2.  Assess  the  costs  and  benefits  of  EDI  for  invoicing. 


III.  ANALYSIS  AND  RESULTS 

A.  MILSCAP.  According  to  the  MILSCAP  manual  (DoD  400.25-5-M,  page 
3-2),  one  of  the  uses  of  the  contract  abstract  by  contract 
administration  offices  is  to  create  a  suspense  for  receipt  of  hard  copy 
requirements.  This  Is  how  payment  offices  are  now  using  the  abstract. 
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When  an  abstract  is  received,  a  data  base  entry  for  that  contract  is 
created.  Two  MAAPR  messages,  AWAITING  HARD  COPY  RECEIPT,  and  MANDATORY 
REVIEW/OTHER,  are  generated.  Until  the  hard  copy  document  of  the 
contract  is  received,  invoices  received  on  that  contract  will  be  paid 
manually. 

Abstracts  generally  are  received  in  one  of  two  forms:  a  "tailored" 
abstract  from  those  activities  not  yet  using  fully  implemented  MILSCAP, 
or  a  fully  implemented  abstract.  The  "tailored"  abstract  contains  just 
enough  data  with  which  to  create  a  suspense  for  receipt  of  the  hard 
copy  contract.  A  full  scale  abstract  contains  all  the  data  intended 
for  abstracts,  but  is  still  slightly  less  than  needed  for  payment. 

Full  scale  implementation  of  MILSCAP  was  deferred  in  1973  due  to 
difficulties  encountered  in  testing.  MILSCAP  abstracts  were  not 
intended  to  be  used  as  the  basis  for  making  payments  to  contractors. 
However,  data  from  a  fully  implemented  MILSCAP  abstract  is  very  close 
to  being  sufficient  for  payments.  Our  research  found  that  finance 
personnel  had  two  main  objections  to  using  abstract  data  for  payments 
--  unreliable  data  and  insufficient  data  to  use  as  a  basis  for  a 
payment. 


1.  MILSCAP  Data  Accuracy.  This  study  did  not  sample  to 
determine  the  MILSCAP  abstract  error  rate.  However,  DCMDS  has  done 
studies  in  the  past  five  years  which  documented  MILSCAP  error  rates 
from  ranges  of  2  percent  to  30  percent.  Management  personnel  at  the 
Defense  Contract  Management  District  South  (DCMDS-MR)  stated  that  the 
lower  end  of  the  spectrum  tended  to  reflect  Army  MILSCAP  error  rates 
with  the  higher  end  generally  representing  DLA  Inventory  Control  Point 
(ICP)  activities.  MILSCAP  data  collected  by  the  DCMDC-C  payment 
personnel  for  a  DLA  Office  of  Policy  and  Plans  (DLA-L)  survey  showed 
that  MILSCAP  transmissions  experienced  a  rejection  rate  of 
approximately  5  percent.  Error  rates  indicate  the  accuracy  of  data  in 
MILSCAP  contract  abstracts  that  transmit.  Rejection  rates  indicate  the 
amount  of  abstracts  that  fail  in  the  transmission  stage. 

In  general,  payment  personnel  were  convinced  that  MILSCAP  data  has  an 
unacceptably  high  error  rate.  This  leads  to  the  self-fulfilling 
prophecy  that  no  one  uses  the  data  because  it  is  bad,  and  the  data  is 
bad  because  no  one  uses  it.  However,  the  MILSCAP  Administrator  at  the 
Defense  Logistics  Standard  Systems  Office  (DLSSO),  assessed  the  MILSCAP 
data  error  rate  as  likely  to  be  no  worse  than  the  MOCAS  error  rate. 

The  data  originates  and  is  generated  by  the  procuring  activity's  data 
base  and  is  transmitted  electronically.  Thus,  this  data  certainly  has 
the  potential  to  be  more  accurate  than  the  data  manually  input  into  the 
MOCAS  system. 

2.  Adequacy  of  MILSCAP  Data  for  Payment.  Research  and 
interviews  concerning  what  additional  data  was  needed  to  make  MILSCAP 
abstracts  comprehensive  enough  for  payment  turned  up  a  fact  sheet 
written  in  1982  by  the  DLA  Comptroller  (DLA-C).  The  fact  sheet  listed 
four  reasons  for  awaiting  the  hard  copy  before  making  any  payments: 
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a.  There  is  no  data  element  for  the  "Evidence  of  Shipment 
Required"  clause. 

b.  There  is  a  limit  of  five  contract  provisions  which  can 
be  identified  in  the  abstract. 

c.  There  are  no  data  elements  for  any  "Certification  of 
Invoice  Required"  provisions.  These  certifications  may  be  by  the 
Accounting  and  Finance  Officer  (AFO),  Administrative  Contracting 
Officer  (ACO),  Procuring  Contracting  Officer  (PCO),  Terminating 
Contracting  Officer  ^TCO),  United  States  Dept,  of  Agriculture  (USDA), 
the  Contractor,  or  an  auditor  from  the  Defense  Contract  Audit  Agency 
(DCAA) . 

d.  There  are  no  data  elements  for  "Mandatory  Review" 
provisions.  These  reviews  may  be  "Lumber,"  "Steel,"  or  "Textile." 

Other  data  elements  that  are  not  included  in  MILSCAP  contract 
abstracts,  but  are  necessary  for  payment  are  remittance  address  (if 
different  from  bid/offer  address),  and  progress  payment  rates.  If  all 
of  these  issues  can  be  properly  addressed,  there  is  no  reason  that 
MILSCAP  contract  abstracts  cannot  be  used  for  invoice  payment. 

3.  Examination  of  MILSCAP  Objections.  Two  objections  to  using 
MILSCAP  for  payment  were  that  contract  provisions  were  not  abstracted 
and  that  there  was  a  five  clause  limit  on  the  MILSCAP  abstract  Special 
Contract  provisions  field.  The  MODELS  program  lifts  the  limit  of  five 
on  the  special  contract  provisions  field  which  solves  both  of  these 
problems.  Another  objection  is  that  better  validation  is  needed.  This 
could  also  be  solved  by  using  the  special  contracts  provisions  field 
for  a  data  element  that  would  validate  the  presence  of  a  signature  on 
the  contract.  Still  another  objection  is  that  the  quality  of  MILSCAP 
data  is  not  good  enough  for  payment  without  having  received  the  hard 
copy  document.  However,  since  SAMMS  data  will  now  be  used  by  MOCAS  for 
payment,  without  hard  copy,  there  should  not  be  a  reason  why  MILSCAP 
data  could  not  also  be  used  for  payment.  A  detailed  analysis  of  what 
is  necessary  to  make  MILSCAP  data  adequate  for  payment  is  found  in 
paragraph  III  B  1  a  of  Appendix  D. 

4.  DoD  Full  MILSCAP  Implementation  Efforts.  Another  problem 
with  using  MILSCAP  abstracts  for  payment  is  the  use  of  "tailored" 
abstracts.  These  abstracts  contain  only  basic  contract  information 
which  Is  used  for  maintaining  a  control  record  for  that  contract. 
Initiatives  are  currently  under  way  in  DLA,  the  Air  Force,  and  the  Navy 
to  convert  activities  using  "tailored"  abstracts  to  fully  implemented 
MILSCAP  abstracts.  The  Army  currently  has  fully  implemented  MILSCAP 
abstracts. 


-  The  OLA  initiative  to  convert  MILSCAP  to  a  fully 
Implemented  system  is  called  "Complete  SAMMS/MILSCAP  Abstract.”  This 
initiative  seems  to  be  progressing  as  planned.  The  current  estimate 
for  implementation  is  September  1991.  DLA  reports  the  progress  of  this 
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initiative  semiannually  to  DLSSO.  Their  last  report  to  DLSSO  (November 
1990)  stated  the  program  was  still  on  schedule  and  that  the 
implementation  date  should  be  met. 

-  The  Navy  initiative,  "ICP  Resystemization,"  will  allow 
both  the  Aviation  Supply  Office  (ASO)  and  Ships  Parts  Control  Center 
(SPCC)  to  transmit  fully  compatible  MILSCAP  documents.  The  currently 
scheduled  implementation  date  is  March  1991.  Unfortunately,  the 
modules  associated  with  contract  abstracts  have  been  pushed  back  about 
a  year.  In  the  current  system,  contracts  for  Foreign  Military  Sales 
(FMS)  contracts  and  contract  modifications  are  not  abstracted.  When 
ICP  Resystemization  is  implemented  these  will  be  transmitted  In  a  fully 
compatible  manner. 

-  Within  the  Air  Force,  the  Air  Force  Systems  Command 
(AFSC)  utilizes  complete  MILSCAP  abstracts,  while  the  Air  Force 
Logistics  Command  (AFLC)  does  not.  AFLC's  initiative  to  convert  their 
contract  abstracts  to  fully  compatible  MILSCAP  versions  is  Contract 
Data  Management  System  (CDMS).  This  effort  was  originally  intended  for 
completion  in  FY  88.  However,  this  date  has  been  pushed  back  further 
and  further  to  the  latest  estimate  of  FY  95,  which  may  still  be 
optimistic.  Due  to  the  slow  progress  and  continuing  setbacks 
experienced,  it  has  become  a  possible  target  for  budget  cutbacks.  The 
AFLC  point  of  contact  for  this  project  has  labeled  the  fate  of  CDMS 
"shaky  at  best." 

Should  MILSCAP  be  fully  implemented  throughout  DoD  Procuring  and 
Administration  offices,  it  is  possible  that  the  enormous  quantity  of 
data  being  transmitted  back  and  forth  could  create  problems  for  those 
activities  that  still  transmit  at  low  baud  rates.  (Baud  rates  are  a 
measure  of  the  speed  of  transmission.  One  baud  equals  one-half 
character  per  second,  e.g.  300  baud  is  150  characters  per  second.) 
However,  these  problems  would  not  be  specific  to  MILSCAP  EDI  uses.  Any 
kind  of  EDI  transmission  utilized  in  great  quantities  would  raise  the 
same  issue.  Regardless,  any  expenditures  to  upgrade  transmission 
equipment  to  necessary  baud  rates  would  likely  be  far  outweighed  by  the 
benefits  of  MILSCAP. 

B.  Electronic  Invoicing.  Contractor  submission  of  invoices  is  an 
excellent  application  of  EDI.  Currently  contractors  submit  a 
commercial  invoice  or  a  DO  Form  250,  Material  Inspection  and  Receiving 
Report,  via  the  U.S.  Postal  Service.  The  invoice  data  is  manually 
input  at  least  twice  (by  the  contractor  onto  the  document  and  by  the 
payment  office  into  M0CAS) .  Errors  can  arise  during  any  part  of  this 
process  and  may  cause  the  invoice  to  be  paid  manually.  Generally,  any 
input  error  concerning  price  or  quantity  will  prevent  API.  Use  of 
electronic  invoicing  will  minimize  input  errors  by  transmitting  data 
directly  from  the  contractor  to  the  Government's  data  base. 

Two  DCMDs  are  currently  using  versions  of  electronic  invoicing. 

Efforts  by  other  districts  have  only  been  on  a  case-specific  basis. 
DCMDN  (Boston)  is  using  magnetic  tapes  to  transmit  invoice  data  from 
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contractor  to  Government.  DCMDM  (Philadelphia)  is  using  an  Electronic 
Bulletin  Board  System  (EBBS)  and  also  a  floppy  disk  system.  DSAC  is 
currently  developing  an  electronic  invoicing  system  for  DFAS. 

1.  DCMDN  EDI  Invoicing  System.  DCHDN's  efforts  using  magnetic 
tapes  have  been  fairly  successful.  The  major  advantage  to  the 
contractor  is  the  ability  to  control  the  quality  of  the  data  input  into 
MOCAS.  The  cleaner  the  data  input,  the  more  likely  the  contractor  is 
to  get  paid  on  time.  The  Government  saves  the  labor  that  would  have 
been  necessary  to  input  the  invoices  manually.  Midsize  to  smaller 
contractors,  though,  are  not  likely  to  benefit  from  this  system.  A 
large  number  of  invoices  is  necessary  to  achieve  payback.  Many  of 
these  smaller  contractors  probably  would  not  have  access  to  magnetic 
tape  equipment  or  technology.  There  is  no  benefit  to  the  contractor  in 
mailing  time,  as  the  tapes  still  must  be  mailed. 

2.  DCMDM  EDI  Invoicing  Systems.  The  DCMDM  initiative  is  the 
Contractor  DD  Form  250  and  Invoice  Electronic  Transmission  (CDIET), 
originated  in  the  former  Cleveland  region.  DD  Form  250  and  invoice 
data  is  transmitted  electronically  using  an  EBBS.  Contractors  upload 
invoice  data  to  the  EBBS.  It  is  then  downloaded  to  a  microcomputer, 
split  out  into  separate  files,  and  finally  uploaded  into  MOCAS.  This 
system  saves  the  contractor  the  two  day  mailing  time,  sends  him  an 
electronic  receipt,  and  controls  the  quality  of  the  data  input  into 
MOCAS.  CDIET  has  two  drawbacks.  Managing  the  EBBS  is  the  Government's 
responsibility,  which  may  be  expensive  to  the  Government  and 
inconvenient  for  the  contractors  if  not  properly  administered.  The 
CDIET  will  not  accept  Bureau  Vouchers  nor  Progress  Payment  Vouchers. 

Another  DCMDM  EDI  initiative  is  the  floppy  disk  system.  This  system 
allows  contractors  to  submit  invoices  in  flat  ASCII  files  on  floppy 
disks.  While  this  may  not  be  "classical"  electronic  data  interchange, 
it  is  convenient  for  both  contractors  and  the  Government.  Contractors 
follow  a  standard  format  and  submit  invoices  in  80  column  rows  in  ASCII 
files.  Submissions  are  then  run  through  a  BASIC  program  to  ensure 
adherence  to  the  prescribed  format.  All  types  of  invoices  (DD250, 
commercial,  progress  payment,  bureau  voucher)  can  be  submitted  through 
this  system.  Hard  copies  of  the  invoices  are  checked  in  and  processed 
along  with  the  floppies.  Invoices  are  then  uploaded  to  a  DMINS  file 
which  is  transmitted  to  MOCAS  daily. 

3.  DSAC  EDI  Work.  The  current  DSAC  effort  (which  is  being 
referred  to  by  DSAC  as  simply  the  "DFAS  Project")  encompasses  most  of 
the  advantages  of  the  other  Initiatives.  This  project  began  Informally 
In  July  1990.  As  of  December  1990,  the  project  had  been  temporarily 
put  on  hold.  No  formal  milestones  have  yet  been  set.  However,  most 
background  work  has  been  completed.  It  has  been  estimated  that 
development  work  will  take  about  8  to  12  months  depending  on  the 
contracting-out  that  is  done.  Very  few  changes  to  existing  software 
and  hardware  are  anticipated,  nor  is  much  equipment  acquisition 
anticipated.  Some  telecommunications  equipment  will  be  needed,  but  the 
requirements  are  not  yet  known.  As  currently  planned,  the  Government 
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will  contract  with  a  Value  Added  Network  (VAN)  to  provide  the 
communications  network.  Contractors  will  contract  with  the  VAN  for  use 
of  the  services.  The  capital  investment  required  of  contractors  by  the 
VAN  should  be  small,  with  the  associated  cost  to  use  the  service  also 
manageable.  When  contractors  submit  invoices  to  the  VAN,  they  are 
transmitted  to  the  DSAC  developed  Logistics  Information  Exchange 
(LINX).  LINX  will  then  separate  the  invoices  into  files  for  each 
district.  MOCAS  receives  these  files  and  processes  the  invoices  for 
payment.  LINX  then  queries  MOCAS  and  gathers  status  information  on 
each  invoice.  This  information  is  then  transmitted  back  to  the  VAN 
where  it  is  made  available  to  contractors.  Pending  GAO  approval,  the 
system  will  also  generate  hard  copy  invoices  of  the  transmissions  for 
file/audit  purposes  if  needed.  All  types  of  invoices  may  be 
transmitted  through  the  VAN. 


IV.  SAVINGS  AND  BENEFITS 

A.  MILSCAP  for  Contract  Data  Input.  Cleaner  and  more  timely  data 
should  reduce  a  great  amount  of  manual  payments  of  invoices,  especially 
those  generated  by  the  message  MAAPR-INV  $  NOT  EQUAL.  The  MAAPRs  with 
this  message  that  are  affected  are  those  where  the  invoice  amount  is 
greater  than  the  MAAPR  amount,  since  another  recommendation  already 
resolves  the  situation  when  the  invoice  amount  is  less  than  the  MAAPR 
amount.  Savings  from  the  MAAPRs  with  this  message  due  to  the 
modification  timing  problem  and  transportation  charge  oversight  are 
detailed  in  paragraph  III  C  of  Appendix  D.  Most  of  the  other  MAAPRs 
with  this  message  are  due  to  either  contractor  invoice,  Government 
input,  or  acceptance  data  input  error.  From  paragraph  B  of  Attachment 
2  to  Appendix  D,  4.2  percent  of  alj.  manual  MAAPRs  are  due  only  to  the 
MAAPR-INV  $  NOT  EQUAL  message,  but  not  the  modification  timing  and 
transportation  charge  oversight  problems.  If  even  half  of  these  MAAPRs 
were  corrected  by  using  MILSCAP  for  contract  data  input,  2.1  percent  of 
all  MAAPRs  could  be  avoided.  The  additional  annual  savings  would  be 
over  $330,000  (nearly  17,000  manual  MAAPRs  avoided,  saving  $19.98 
each) . 

Savings  will  also  be  realized  in  the  area  of  contract  data  input  and 
MILSCAP.  There  are  approximately  185  contract  input  clerks  throughout 
DCMC,  with  89  inputting  original  contracts  and  96  inputting  contract 
modifications.  Based  on  an  average  grade  of  GS-5  Step  5,  and  benefits 
of  29.55  percent,  these  clerks  cost  about  $4.61  million  per  year.  These 
costs  are  the  same  as  those  already  detailed  in  Appendix  D  for  data 
input  clerks. 

B.  EDI  for  Invoice  Input.  The  use  of  EDI  technology  in  the  area 
of  invoicing  should  result  in  a  dramatic  reduction  in  manual  input 
effort.  Every  invoice  transmitted  electronically  corresponds  to  one 
less  that  has  to  be  input  manually.  There  are  approximately  110 
invoice  input  clerks  throughout  DCMC.  Based  on  an  average  grade  of 
GS-4  Step  5,  and  benefits  of  29.55  percent,  these  clerks  cost  about 
$2.45  mill  ion  per  year. 
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Workyear  savings  are  not  the  only  benefit  to  the  use  of  electronic 
invoicing.  Cleaner  and  more  timely  data  should  result  in  more  timely 
contractor  payments.  This  would  reduce  interest  payments  made  to 
contractors  and  increase  goodwill. 


V.  CONCLUSIONS 

EDI  technology  can  significantly  increase  the  accuracy  of  the  MOCAS 
data  base  as  well  as  maximize  the  use  of  the  API  system.  MILSCAP,  when 
properly  modified  and  updated,  is  a  cost  effective  way  to  eliminate 
costly  errors  due  to  the  repetitive  manual  input  of  contractual  data. 
Furthermore,  when  a  properly  utilized  MILSCAP  system  is  coupled  with  an 
EDI  system  for  invoice  data,  the  Government  can  realize  dramatic 
savings.  These  savings  stem  from  two  benefits  associated  with  the  use 
of  EDI  in  the  contract  payment  area.  The  first  is  a  reduction  in 
clerical  effort  necessary  for  data  Input.  The  other  is  cleaner  and 
more  timely  data. 

The  previously  mentioned  ELG  for  Defense  Corporate  Information 
Management  stated  in  their  situation  analysis  for  DoD  Information 
Management  that  "Data  entry  in  many  functional  areas  remains  a  labor 
intensive  activity,  subject  to  many  errors  and  often  requiring 
reentry."  They  further  stated  that  "Electronic  transmission  of 
documents  exists  in  limited  applications  within  DoD.  Currently,  much 
data  exchanged  between  DoD  and  its  suppliers  exists  in  digital  form, 
but  mi'^t  be  converted  to  hard  copy  for  use  by  the  Department."  The 
ELG' s  "Vision  of  the  Future  -  DoD  Information  Management  in  the  Year 
2000"  stated  that  by  the  year  2000  they  expected  that  "non- value  added 
work  had  been  reduced,"  "most  data  are  being  entered  into  information 
systems  without  being  handwritten  or  typed,"  and  "electronic  data 
interchange  and  funds  transfer  are  now  in  place,  speeding  financial 
transactions  and  the  exchange  of  technical  and  management  information." 
One  of  the  14  "Guiding  Principles"  used  by  the  ELG  was  "Data  will  be 
entered  only  once."  A  fully  and  properly  implemented  MILSCAP  system, 
in  coordination  with  a  functional  electronic  invoicing  system  will  lead 
the  payment  function  away  from  today's  labor  intensive  activity  and 
toward  the  ELG's  vision  of  the  future. 


VI.  RECOMMENDATIONS 

A.  MILSCAP  Enhancement.  A  system  to  transmit  standard  DoD 
contract  data  electronically  is  vital  to  efforts  to  further  modernize 
contract  payment  functions.  MILSCAP  is  the  means  of  doing  this  now. 

No  doubt,  MILSCAP  has  developed  a  poor  reputation  over  the  years. 
However,  it  is  very  likely  that  a  replacemen'  system  would  look 
remarkably  similar  to  the  MILSCAP  of  today  and  be  far  more  costly  than 
altering  MILSCAP.  MILSCAP  contract  abstracts  were  not  originally  to  be 
used  for  payments.  But  they  could  be  with  some  concerted  efforts. 
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The  MODELS  (Modernization  of  Defense  Logistics  Systems)  work  done  by 
the  Defense  Logistics  Standards  Systems  Office  to  enhance  MILSCAP 
should  be  coordinated  with  the  OLA  initiative,  titled  "Complete 
SAMMS/MILSCAP  Abstracts,"  to  convert  MILSCAP  abstracts  to  a  fully 
implemented  system.  This  effort  should  ensure  that  the  MILSCAP 
contract  abstract  and  modification  contain  all  of  the  Information 
necessary  for  payment  to  be  made.  DFAS  should  have  a  key  role  in 
reviewing  the  goals  of  this  overall  effort.  This  integrated  effort 
should  address  the  following  areas: 

1.  The  MOOELS  program,  as  described  in  the  section  above, 
needs  to  be  implemented  in  all  procuring  and  contract  administration 
activities  as  expeditiously  as  possible.  The  conversion  from  fixed 
length  records  to  variable  length  records,  along  with  the  addition  of 
necessary  MILSCAP  data  fields,  will  allow  for  the  transmission  of  as 
many  special  contract  provisions  as  necessary. 

2.  The  use  of  "tailored"  abstracts  should  be  phased  out  as 
soon  as  possible.  DLA,  Navy,  and  Air  Force  all  have  initiatives  in  the 
works  to  accomplish  this.  However,  the  Air  Force's  effort,  Contract 
Data  Management  System,  has  historically  progressed  slowly  and  now  its 
future  is  ir  doubt.  DLA  and  DFAS  should  exert  influence  to  see  that 
this  project  continues  and  is  completed.  For  example,  the  DFAS  could 
mandate  a  surcharge  for  all  vouchers  from  buying  activities  that  don't 
use  EDI  technology  to  transmit  payable  contract  and  modification  data. 
Completion  of  all  three  of  these  efforts  will  allow  for  the 
transmission  of  fully  implemented  abstracts  and  modifications  adequate 
for  payment. 

3.  Potential  benefits  include  eliminating  tens  of  thousands  of 
manual  payments,  each  at  a  cost  of  $19.98,  and  eliminating  the  clerical 
staff  inputting  contract  information,  which  currently  numbers  185. 

B.  Electronic  Invoicing 

1.  DLA  should  develop  and  support  a  single  electronic 
invoicing  system.  The  DSAC  electronic  invoicing  initiative  is  a  way  to 
accomplish  this. 

2.  The  requirement  of  contractors  to  make  a  small  capital 
investment  to  use  the  VAN,  along  with  the  requirement  to  contract  with 
the  VAN,  m ty  preclude  smaller  contractors  from  taking  advantage  of 
electronic  invoicing.  The  volume  of  Government  contracting  these  firms 
have  may  n«,t  justify  their  spending  for  VAN  usage.  However,  the 
Government  would  still  benefit  from  its  usage  by  large  contractors.  To 
get  EDI  benefit  for  smaller  contractors  DLA  should  continue  to  support 
the  floppy  disk  invoicing  system. 

3.  Potential  benefits  include  reducing  clerical  staff  by  the 
approximately  110  necessary  to  input  contractor  invoices,  and 
increasing  the  number  of  payments  made  on  a  timely  bas!s  due  to  cleaner 
and  more  timely  data. 
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